The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Content last reviewed 2023-02-15
The Create stage helps teams accelerate software delivery and reduce cycle times, by improving efficiency and collaboration. Essential to software delivery, is the process of creating each improvement. The Create stage delights engineers, designers, and product managers with tools to design, develop, and review these improvements efficiently.
The Create stage is made up of one DevOps stage, Create, and five groups including:
The existing team members for the Create stage can be found in the links below:
Source code management (SCM) is the foundation of an organization's software development practice. SCM tools provide the interface and controls that teams use to define the rules and workflows their developers operate within to write code and collaboratively produce software. At any size of company, it is critical that the SCM tool be intuitive to aid in productivity, streamline collaboration for reviews across teams and functions, ensure compliance, and enable best development and security practices. However, these challenges become more acute and more difficult to solve at the enterprise level. The larger an organization becomes, the greater their communication and coordination overhead is since there are more numerous, bigger, and broadly distributed teams trying to work together. To address this, the industry is adopting DevSecOps practices to increase velocity and reduce cycle time. Selecting an SCM tool is the first step on that journey.
As examples, GitLab will provide:
Security is a team sport and organizations benefit the most when the developers have it top of mind. The most successful teams integrate security practices into code reviews and even into the actual writing of code. Source code management platforms typically offer this functionality via integration with multiple other tools, bolted on. This creates context-switching and inefficiencies. SCM tools that offer security testing natively understand how critical a developer’s time and attention span are to producing great software rapidly. By purchasing tools that make the “required tasks” (i.e. approvals, security, compliance) enjoyable and low-effort, companies retain happy development talent while meeting regulations, preventing breaches, and shipping software frequently. You can read more about shifting left on the Secure stage vision.
As examples, GitLab will provide:
The developer experience is defined by development velocity, safety, and how it enables innovation and iteration. Investing in the Developer Experience therefore drives revenue and reduces risk for organizations. To provide a strong DX, a company must purchase tools that are highly usable & reliable, organized to support the developer journey, reduce context switching, and minimize decision fatigue. Such tools can significantly increase developer productivity by automating the manual repetitive tasks, removing the need for the individual developer to maintain local environments or worry about keeping libraries and dependencies up-to-date, and providing a central internal developer portal for project, process, product, and API documentation with an intuitive and beautiful UI.
As examples, GitLab will provide:
In three years the Create stage market will:
As a result, in three years GitLab will:
The Create stage has been actively delivering updates to help your development teams collaborate faster and more effectively. Here are some highlights from recent releases:
To meet our big hairy audacious goal, the Create stage will focus on the following this year:
The following will not be a focus over the next 12 months:
GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.
Source code management enables coordination, sharing, and collaboration across an entire software development team. GitLab supports teams to rapidly collaborate and iterate on new features and deliver business value. This category is at the "lovable" level of maturity.
Priority: high • Learn more • Documentation • Direction
Review code, discuss changes, share knowledge, and identify defects in code among distributed teams via asynchronous review and commenting. Automate, track and report code reviews. This category is at the "lovable" level of maturity.
Priority: high • Learn more • Documentation • Direction
A full featured Integrated Development Environment (IDE) built into GitLab so you can start contributing on day one with no need to spend days getting all the right packages installed into your local dev environment. This category is at the "complete" level of maturity.
Priority: medium • Documentation • Direction
A GitLab CLI to support developers where they work and how they work with GitLab. This category is at the "viable" level of maturity.
Priority: medium • Documentation • Direction
Editor Extensions to support integrations between GitLab and Local Development Environments.
Priority: high • Documentation • Direction
Accelerate your workflow and ensure a consistent developer experience by ditching your local environment and moving to standardized, secure, remote development environments. This category is at the "minimal" level of maturity.
AI Assistant for proactive coding suggestions and autocompletions This category is at the "viable" level of maturity.
These JTBD relate to the Code Review group. The statements were drafted for the FY21-Q2 Category Maturity Scorecard and have not been validated yet.
Job statements | Maturity | Confidence | Source |
---|---|---|---|
When product improvements are identified, I want to propose changes that address them, so that I can help build a better product. | Not validated | Issue | |
When my teammates propose changes, I want to review them before they are accepted, so that I can help increase the quality of changes, minimize the risk of defects, minimize the risk of out-of-scope changes, and grow the team’s expertise. | Not validated | Issue | |
When my teammates propose changes, I want to ensure they are reviewed and accepted according to internal guidelines, so that we can increase the quality of changes, minimize the risk of defects, and maximize the reliability of product data. | Not validated | Issue |
When I am deploying a static site I want to use kubernetes for my cloud native installation so I can leverage auto-devops and other benefits of K8.
Job statements | Maturity | Confidence | Source |
---|---|---|---|
When I have a custom domain or multiple domains I want to be able to redirect the other domains to my custom/main domain so I can optimize SEO rankings and ensure traffic from like domains are tracked. | Issue | ||
When I am setting up a static site I want to be able to set up the site with a wildcard DNS so I can avoid setting up a custom domain. | Issue |
These JTBD relate to the Source Code Management category. These statements have been drafted for the FY24-Q1 Category Maturity assessment and have not been validated, yet.
Job statements | Maturity | Confidence | Source |
---|---|---|---|
When code is meant to be private and restricted to a certain group of contributors, I want to control the access to the source code, so that I can protect the investments in intellectual property and to reduce the risk of source code exploitation. | Not validated | Issue | |
When reviewing past code changes, I want to track changes and manage different revisions of the source code, so that I can identify which changes were made and when, and to reference an earlier revision if necessary. | Not validated | Issue | |
When developing source code with multiple people, I want to set the rules for the collaboration, so that collaborators can explore changes and contribute efficiently. | Not validated | Issue | |
When changing source code, I want to set conditions for applying these changes, so that code quality and compliance is maintained. | Not validated | Issue | |
When working with large binary files, I want to version control these files with the source code, so that I can track and manage changes to the files over time. | Not validated | Issue |
The Create stage pricing strategy balances the needs of individual contributors, with the needs of enterprises, to create a cycle where individual contributors gladly and rapidly adopt GitLab, and naturally create the business case for upgrading to a suitable tier, typically Premium and above. The core pillar of the Create stage is the merge request based development workflow. This touches Source Code Management, Code Review and the Web IDE, and is heavily influenced by individual developers, and managers who implement access controls for efficiency, security, quality and compliance purposes. Our investment and pricing philosophy is to:
The tier for individual contributors, personal projects, or small teams trialing GitLab. Free is important for retaining our core users Developers (SCM, Code Review, Web IDE) and exploring different avenues of expansion in the types of personas who contribute to GitLab and their use cases. Expanding support for different markets and use cases through improved binary file and monolithic repository workflows and more accessible editing tools begins at the individual contributor level, as does supporting new personas like designers and marketers.
Examples:
The tier for teams, Premium is enterprise ready and delivers important access controls and workflow controls needed for multiple teams to collaborate on the same large project. The Premium tier features for Source Code Management and Code Review are already mature, and very valuable to medium and large enterprises. Many feature requests and improvements driven by Premium customers are improvements to the experience of individual developers, which facilitates growth through expansion and standardization on GitLab.
Examples:
The tier for Executive buyers with strategic objects for their business, this tier is primarily supported through Audit and Compliance capabilities that extend project level access control features.
In the future we intend to establish an Ultimate offering for Create. It will likely include:
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!
Last Reviewed: 2021-03-08
Last Updated: 2021-03-08