このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
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.
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.
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.
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.
Our top focus is making release management easier for users across mutliple projects. The main features that will enable this are release generation from .gitlab-ci.yml (gitlab&2510), enabling the specification of asset link types via (gitlab#207257).
Users can now effectively track their Release Plans in context to a release via (gitlab#9427), we are going to be investing in supporting advanced controls for deployment windows with our Deploy Freeze MVC via (gitlab#24295), enabling users to refine when an environment can be deployed to.
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 editing a release capability directly from the Release page will progress the maturity to Complete. The Releases page will connect the issues assigned to specific milestone and/or release automatically into the workflow, delivering a single view for a release.
Key deliverables to achieve this are:
.gitlab-ci.yml (Complete)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.
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 epecially true as we begin to support more non-technical personas by enhancing the UI experience of release orchestration that many enterprises are interested in.
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# and supporting DORA 4 metrics via gitlab#37139, will move the needle for these audiences.
In the same vein as (gitlab#26015), issues that will support the ease of use of releases across multiple projects, such as associating releases to group milestones in gitlab#121476 are becoming extremely relevant for our customers.
Our users and organizations leveraging GitLab at scale, are struggling with the current permission paradigm. We have received lots of traction on adding a deployer role via gitlab#201898.
Implementing (gitlab#36133), which makes creation of the release package an inline part of the .gitlab-ci.yml, will make this feature feel much more mature and production-ready (even if it is already really usable).
A second top customer request is to auto-generate release notes from annotated tags via (gitlab#15563).
Lastly, we have validated we need to support adding assets to a release (gitlab#27300) and are looking to support uploading files to the Release in gitlab#208712 by creating a generic raw package registry. The connection of releases and assets will improve the richness of the release page, helping users see the full picture of their release in a single place.
A lot of interest has been expressed in adding the ability to clean up stale environments in the UI (gitlab#19724).
The pain of navigating and triaging release tasks across projects within groups have also been researched in (gitlab#197114). We are looking to make coordinating deployments in GitLab easier to be implemented by supporting environments at the Group via (gitlab#196168) alongside association of Releases to Group Milestones via (gitlab#121476).
This YouTube video on the Release Stage vision, captures much of the longer term focuses for usability, maturity, and nimbleness of orchestrating releases in GitLab:
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.