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, but also recognizes that there are manual steps and coordination points involving human decisions throughout software delivery in the enterprise. More specifically, this is managing the kinds of complex enterprise releases for which you'd have a Release Manager in play, rather than having individual teams continually deploying independent code to production.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
One important consideration for how we want to implement release orchestration at GitLab is that we want to solve automated, continuous delivery workflows first. We believe that all enterprises can achieve this, and that GitLab as a whole is a powerful tool to unlock efficiency within DevOps. As such we avoid adding manual, non-automated controls to the delivery pipeline. That's not to say we don't want to hear about problems that are currently being solved with manual process, or that we just don't want to address them, but we want to work with you to creatively find ways to solve these with automation. Only if that becomes untenable do we want to look at other options. Ultimately we believe this is best for GitLab and for our users; we'd much rather see people doing release management using the data that already exists, by using our tool for day to day actions and processes and not having to do any manual work on top of it.
Our top focus is to support ease of use for release management in GitLab. The two main features that will enable this are release generation from
.gitlab-ci.yml (gitlab#26013) and filtering issues in a release (gitlab#32632). To support our users deliver software faster with GitLab, we are validating how to add assets to a release (gitlab#27300). This 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.
This category is currently at the "Minimal" maturity level, and our next maturity target is Viable (see our definitions of maturity levels). We believe that expanding editing a release capability directly from the release page will progress the maturity to Viable. The release 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:
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. In Gartner's recent review of ARO tools, the strategy to focus on modern application development and delivery workflows was celebrated and validated.
An important view for the way we look at the world is gitlab#3713 which introduces an environments-based view for managing what's deployed.
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.
In the same vein as gitlab#26015, issues that will support the ease of use of releases like being able to create a release in the UI (gitlab#32812] is an issue of interest to satisfy prospect use cases.
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 https://gitlab.com/gitlab-org/gitlab/issues/15563.
An exciting item for the vision is the ability to create releases as runbooks via gitlab#9427. This will allow non-technical users to create runnable release plans in GitLab, which can have actions embedded in them which will perform automated parts of the release.
We are beginning to research linking runbooks to Releases in gitlab#36994, building out the vision for the Release Page to be a single source of truth for project releases.