Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Release Orchestration

Release Orchestration

Release Orchestration is the ability to coordinate complex releases, particularly across projects, in an efficient way that leverages as-code behaviors as much as possible. We also recognize that there are manual steps and coordination points involving human decisions throughout software delivery in the enterprise. In these cases, there are teams and release manager roles dedicated to groundguiding these complex enterprise releases, rather than individuals continuously deploying to production.

Manual Processes vs. Automation

At GitLab we believe organizations can accomplish these enterprise grade releases elegantly and effectively with automation. We are a powerful platform that unlocks efficiency within DevOps. As such, we avoid adding manual, non-automated controls to the delivery pipeline. We have completed a competitive analysis of tools that help manage dependencies and advance deployment orchestration in gitlab&4635. There are many ways GitLab can improve the quality of life for organizations and teams managing deployments.

A related category in the Configure stage describes one approach for users to embrace an infrastructure as code approach to tasks in the catgeory of Runbooks. Release Management will be making contributions to this direction as we begin to support more demands for workflows within the GitLab platform.

Compliance and Security in the Release Pipeline

Security, compliance, control and governance of the release pipeline is handled as part of Release Evidence. Secrets in the pipeline are part of our Secrets Management category. Another category for governance and security within GitLab is Compliance Management, which is inclusive of change management and approval workflows. For governance workflows pertaining to issues and requirements, check out our category of Requirements Management from the Plan stage.

What's Next & Why

We are currently working on improving the environments experience via gitlab#300741. In this issue we are introducing a way to tag environment types in the gitlab-ci.yml. Some of our features, such as DORA4 metrics rely on a specific environment name to indicate that the environment is a produciton environment. In order to allow more flexability and support more than one production environment in these features, we are introducing the environment type keyword which will allow you to choose any environment name but to set it to a produciton type.

We are also working on a way to clean up stale environments in gitlab#296625 which will improve performance on GitLab.com.

Maturity Plan

This category is currently at the "Viable" maturity level, and our next maturity target is "Complete" (see our definitions of maturity levels).

We believe that expanding interactions from the Release page will progress the maturity to Complete. The Releases page will connect the issues assigned to specific milestone and artifacts generated from a deployment, delivering a single view for a release.

Key deliverables to achieve this are:

Competitive Landscape

Release orchestration tools tend to have great features for managing releases, as you'd expect; they are built from the ground up as a release management workflow tool and are very capable in those areas. Our approach to release orchestration will be a bit different, instead of being workflow-oriented we are going to approach release orchestration from a publishing point of view. What this means is instead of building complicated workflows for your releases, we will focus more on the artifact of the release itself and embedding the checks and steps into it.

Gartner listed GitLab as a challenger in Application Release Orchestration, celebrating the "single product" offering of GitLab as "cloud-native, with a large and rapidly growing customer base". The blurring of the market with the convergence of features across various tools in ARO, CI/CS, PaaS, means functionality like AutoDevops and release automation is advantageously positioned to solve the problems of more traditional ARO solutions. Forrester recently listed GitLab as a Strong Performer for the Continous Delivery and Release Automation Wave, highlighting the advanced controls of release ochestration for cloud native applications. GitLab's ranking as a Forrester Strong Performer is reviewed in a published blog. We are looking forward to administration of releases at scale via gitlab&3298, where we will re-design the current Environments Dashboard for management of legacy style deployments. Gartner's 2020 Peer Insights' 'Voice of the Customer' synthesized hundreds of reviews and ratings from the perspective of peers to help IT decision makers choose the best solution them. We're excited to be recognized as a "Customers' Choice" for Application Release Orchestration based on the qualifications set by Gartner Peer Insights.

Gartnerpeerinsights

We have conducted a detailed analysis of XebiaLabs' XL Release offering in (gitlab#2369). XL Release's elegance of cross team views, administration of deployments and environments as well as actionable metrics for how Releases are performing are all areas of note. We will be able to compete pointedly by offering deploy freeze capabilities and runbook visibility. Where we will strengthen our approach and confidence in head to head scenarios with XL, will in our next validation tracks. In light of this analysis we aim to improve our experience with environment features like roll backs via (gitlab#198364), blue green deployments with (gitlab#14763) and support a better view at the group-level in with director-level dashboard for Releases in (gitlab#3277). Despite the merger of XebiaLabs by CollabNet, GitLab will continue to thrive as a result of the single platform, single data model. This is especially true as we begin to support more non-technical personas by enhancing the UI experience of release orchestration that many enterprises are interested in.

Implementing a compelling deployment plan or native runbook offering, such as discussed in gitlab&4218, will help us more holistically compete with Electric Cloud, as discovered in the competitive analysis conducted in gitlab&3917.

Analyst Landscape

Analysts at this time are looking for more quality of life features that make a difference in people's daily workflows - how does this make my day better? By introducing features like (gitlab#26015) to automatically manage changelogs and release notes as part of releases, we can demonstrate how our solution is already capable of doing this.

Deploy freezes (gitlab#24295) will help compliance teams enforce periods where production needs to remain stable/not change. The 2020 CDRA Wave Analysts featured criteria around scheduling for maintenance windows, which deploy freezes would satisfy.

Legacy deployment methods, calendar view for deployments and being able to see across a portfolio of releases is becoming more and more relevant as Analysts rank competing solutions like Digital.ai and Cloudbees. Better analytics and reporting, such as the CI/CD dashboard in gitlab#199739 and supporting DORA 4 metrics via gitlab#37139, will move the needle for these audiences. Native runbooks, as discussed in gitlab&4218, are well-positioned to address the need to support non-cloud native deployment plans and are a direct response to rankings on support of legacy deployment methods from the 2020 CDRA Wave.

Top Customer Success/Sales Issue(s)

Some customers are looking for deeper seperation of duties and have requested the ability to introduce a new permission setting for allowing specific users or roles to create/edit or delete protected environments in gitlab#262011

Top Customer Issue(s)

Auto-generating release notes from annotated tags via (gitlab#15563) can help with automating release orchastration and eliminate redundant work.

Top Internal Customer Issue(s)

A lot of interest has been expressed in adding the ability to clean up stale environments in the UI (gitlab#19724).

Top Vision Item(s)

This YouTube video on the Release Stage vision, captures a walkthrough of our 3 year mocks for our broader vision for the release stage:

We are currently designing and thinking about how to better connect the Package stage with Releases. We are seeing a great use case for adding semantic versioning to Releases as outlined in gitlab#213838, as well improving the Versioned Dependencies category by implementing better connections between the Release's page of project and the packages created via gitlab#215390.

We have begun investigating the extension of Merge Trains to include final deployment jobs, which are preliminarily called Release Trains, via gitlab#268246.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license