Our vision is to replace disparate DevOps toolchains with a single application that is pre-configured to work by default across the entire DevOps lifecycle.
We aim to make it faster and easier for groups of contributors to deliver value to their users, and we achieve this by enabling:
Our solution plays well with others, works for teams of any size and composition and for any kind of project, and provides ongoing actionable feedback for continuous improvement.
You can read more about the principles that guide our prioritization process in our product handbook.
DevOps is a broad space with a lot of complexity. To manage this within GitLab, we break down the DevOps lifecycle into a few different stages, each with its own direction page you can review:
Overall visibility and insight into what's happening within GitLab
Planning capabilities to keep your team synchronized and moving in the right direction
Create, view, and manage code and project data through powerful tooling
Keep strict quality standards for production code with automatic testing and reporting
Manages the packages you build and depend on in your software delivery process
Continuous delivery and orchestration of your releases to your users
Automation to configure your applications and infrastructure
Monitor system behavior to understand the impact of changes on your system
Security capabilities, directly integrated into your development lifecycle
Defend your apps and infrastructure from security intrusions
Supporting the stages in the DevOps lifecycle, there are additional Enablement groups, again with their own direction pages:
Our strategy and FY20 plan for the product are comprised of a few key concepts:
We aim for market leadership in every category we compete in. We're already there with:
For FY20, and we'll build best-in-class, lovable features in:
We wouldn't be true to our ambition if we stopped with our current product categories. Across our existing DevOps stages we'll continue to rapidly expand with new categories.
GitLab enables everyone to contribute. Our platform can be used by all people contributing to digital content.
We've already built great workflows and dashboards for:
We are investing in our relatively new roles:
We plan to expand to more roles in FY2020:
Other candidates:
Use cases represent content types (web applications, static websites) and collaboration workflows (idea to production, publishing). Gitlab continues to deliver and replace the disparate DevOps toolchain for both static content and traditional web applications. These are two examples of use cases. We're actively investing in more robust support for new use cases such as cloud native and mobile apps, but we aren't done there. GitLab will expand to enable collaboration on new use cases.
In FY20, we're targetting:
Future use cases:
We are also tracking big initatives for the entire company or for the application at a holistic level that impact the product. These items have their own planning and goals, and typically bridge several (and in some cases even all) of the stages in the product. Some have formal working groups. There are other formal working groups that are not mentioned here as this list focuses on efforts that Product is directly involved with.
In addition, there are broad efforts to "level up" the Product org:
GitLab comes in 4 editions:
As we add new categories and stages to GitLab, some areas of the product will be deeper and more mature than others. We publish a list of the categories, what we think their maturity levels are, and our plans to improve on our maturity page.
To make sure our goals are clearly defined and aligned throughout the organization, we make use of OKR's (Objective Key Results). Our quarterly Objectives and Key Results are publicly viewable.
GitLab's direction is determined by GitLab the company, and the code that is sent by our contributors. We continually merge code to be released in the next version. Contributing is the best way to get a feature you want included.
On our issue tracker for CE and EE, many requests are made for features and changes to GitLab. Issues with the Accepting Merge Requests label are pre-approved as something we're willing to add to GitLab. Of course, before any code is merged it still has to meet our contribution acceptance criteria.
At GitLab, we strive to be ambitious, maintain a strong sense of urgency, and set aspirational targets with every release. The direction items we highlight in our kickoff are a reflection of this ambitious planning. When it comes to execution we aim for velocity over predictability. This way we optimize our planning time to focus on the top of the queue and deliver things fast. We schedule 100% of what we can accomplish based on past throughput and availability factors (vacation, contribute, etc.).
See our product handbook on how we prioritize.
On our releases page you can find an overview of the most important features of recent releases and links to the blog posts for each release.
GitLab releases a new version every single month on the 22nd. You can find the major planned features for upcoming releases on our upcoming releases page.
Note that we often move things around, do things that are not listed, and cancel things that are listed.
Moonshots are big hairy audacious goals that may take a long time to deliver.
.gitlab-ci.ymlStarter features are available to anyone with an Enterprise Edition subscription (Starter, Premium, Ultimate).
Premium features are only available to Premium (and Ultimate) subscribers.
upstream: dependency MVC 11.11not in issue/mr/epic list views and boards Backlogor in issue/mr/epic list views and boards BacklogUltimate is for organizations that have a need to build secure, compliant software and that want to gain visibility of - and be able to influence - their entire organization from a high level. Ultimate features are only be available to Ultimate subscribers.
