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.
This is the product direction for the Release stage. This direction is aligned with the broader Delivery Direction.
Help our customers deploy software to production and make it available to users.
Our vision is to enable organizations and teams to perform all software deployment activities easily, confidently, and safely. GitLab helps teams collaborate on what needs to be done to ensure software is ready to be shipped to production. GitLab aims to automate as much of these activities as possible leveraging existing data and integrating with other DevOps stages in the platform.
Our mid-term product strategy is defined below by key principles and a prioritized set of opportunities to pursue.
Key principles:
Opportunity: Deployment visibility and quick actions to deploy quickly for technical teams
Many teams are deploying using CI pipelines or even GitOps with GitLab and sometimes, other tools today. However, these activities are not well represented in the UI. A simple example - a team may have a deployment pipeline defined in their .gitlab-ci.yml file that consists of jobs that execute scripts related to deploying a version of code to a production environment. Since these deployment pipelines are buried within the other pipeline definitions, they are difficult to track. We assert that deployments are special types of pipelines that warrant their own view and treatment. In other words, we want to make deployments and other related deployment-time concepts like services first class citizens in GitLab.
Teams need to be able have a historical view of deployments. They need to see the status of an ongoing deployment. They need to understand the health and status of production and other environments. They need to have structure and standards around their deployment processes to meet compliance and auditing needs. They need to quickly and easily promote code through environments all the way to production. They need to rollback problematic deployments. There is opportunity to support these types of activities within the UI for both push-based and pull-based deployments. All of these activities are core to releasing new features to production and apply to virtually all teams doing software development. Furthermore, because deployment occurs after upstream activities that are likely being done GitLab already, there is ease of integration with other features in the product and helps differentiate deployment presentment and execution from competitors that don't have all of this activity in one system.
We have made significant progress with the above with the environments page redesign, deploy approval, and utilities to help manage environments. We are now starting to focus on helping users deploy and understand their multi-project application deployments. This builds on the existing foundation laid out above. Examples of these types of problems include tracking deployments across multiple projects, coordinating deployments between teams, and understanding what is being deployed at a given time by teams.
Opportunity: Deploy approval support
Certain customer segments in highly regulated industries such as government or banking, require ways to ensure and audit that deployments to special environments to production are approved by the necessary parties for compliance.
For the past few months, we have shipped iterations to the Deploy Approval feature have seen growth in the usage of this feature and a corresponding growth in overall adoption of deployments. This feature is strategic since it potentially unlocks to new customers to GitLab that require this compliance before they adopt it for deploying. Additionally, it is a key feature to making the product a source of truth for auditing, and thus more valuable, and has the potential to bring in net new users to GitLab, such as Release Managers, tech leads, QA, or others that may need to be involved with approving deployments.
Opportunity: Onboarding Today, x% of customers use the Release stage. There is opportunity for increasing this figure significantly by increasing awareness of environments, deployments, and releases in GitLab during key upstream touchpoints in the user journey of adopting GitLab.
Opportunity: Release orchestration and processes automation After developing tools to visualize and trigger deployments that are mostly driven by pipelines or IaC, we will turn our attention to helping organizations solve the release orchestration process, giving them tools to plan and execute releases from the UI.
Opportunity: Advanced Deployment strategies to deploy even faster After solving the release execution process, we will build more advanced deployment capabilities for users to allow them to smartly, safely, and quickly deploy features.
Opportunity: Deployment setup with UI
We build solutions targeting the following personas:
The Key Performance Indicator for the Release stage is the Release SMAU (internal).
We are currently focusing on improving the experience for Environments. We believe that environments is the centralized place for users to think about and manage their deployments, and currently it is the main link between CI pipelines and representing deployments in environments in the product. We want to make the Environment and related the deployment workflow user experience as useful as possible to encourage more adoption of the feature from existing customers as well as ensure prospect customers have the robust deployment safety and scalable tools they require when they purchase the product.
One important feature that we have seen rapid adoption of and will continue iterating on to support more use cases is Deployment Approval. Please see what's next for environment management for more details about the category. We are also scoping opportunities to link our existing features to each other, such as Environments and Releases, as well as linking them to other stage functionality, e.g. Releases and Packages. One key feature we are scoping is to Add Environments support to the GitLab Agent so that users can easily see what is running in or being deployed to a cluster.
After further progress on environment management and cross-stage features, we will return our focus on Release Orchestration to enable our customers to coordinate complex and multi-project releases. Furthermore, we will continue to add more instrumentation so we have a better understanding of how existing users are leveraging the Release stage capabilities and what opportunities we have to increase adoption of key features such as Environments.
Many of the Release Stage categories such as Feature Flags and Advanced Deployments are not prioritized at the moment, though they are very important to the stage. We want to continue and push forward our leadership in the CI/CD category and thus are heavily focusing on Environment Management and Release Orchestration since they directly support this goal.
Q4 OKRs for the Release Stage (internal)
| Project | What | Why |
|---|---|---|
| Deployment approval iterations | Continue iterations for the feature including notifications, possibly Deployment page, more complex use cases | Increase feature usage and adoption. This feature enables a key workflow that help customers adopt GitLab as a whole and/or upgrade to ~"GitLab Premium". ~"deployment-direction" |
| Group Environments | Ship iterations for group environments. | Highly requested feature for large organizations to understand their application and production environment. Impact to Environments MAU. ~"deployment-direction" |
| Kubernetes Agent and Environments MVC | Partner with ~"group::configure" and design and ship a first iteration for integrating Environments and the K8s Agent | Building this will increase Environments page MAU and help increase K8s Agent adoption (one of the OKRs for ~"group::configure") and also supports Ops CMAU goal. ~"deployment-direction" |
| Onboarding experiment | Ship an experiment that encourages users to create a deployment job to a production environment |
This has a potential for outsized impact to SMAU growth rate since our SMAU is currently based on the number of users who deploy to a GitLab environment. |
| Environments Cleanup | Help users manage large numbers of environments. Ship a way for users to cleanup stale environments. | Highly requested feature. Larger number of environments are currently difficult to manage and navigate. Will impact usability/efficiency and MAU of the page |
| Promotion to Production workflow | Provide a method for users to configure and execute promotion of code from dev, to staging to production. | Key workflow that we removed recently. Users definitely want this and we want to provide an easy, but also robust way for them to configure and execute this common workflow. |
| Usability benchmark improvements | Ship improvements to usability as recommended from the usability benchmark study conducted in Q3 | Help improve usability of the product |
| Environment search performance | Ship follow up improvements to make sure the search feature is performant on SaaS | This is critical for ensuring overall .com reliability. Improvements include instrumentation, and design changes to support performant queries |
| Error budget improvements | Ship improvements to help with error budget | Improve availability of Release Stage features |
source (internal): https://gitlab.com/gitlab-org/ci-cd/release-group/release/-/issues/196
If you are interested specifically in what we are working on next, please see our plans for the 15.10 milestone. For a medium term view of our plans, please see our roadmap. If you have questions or feedback, please reach out via this issue!