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 enterprise releases for which you'd have a Release Manager in play, rather than having individual teams continually deploying independent code to production.
These kinds of releases can still be automated to a large extent, especially at the per-project level, but there is a human aspect in play that's very important in terms of keeping the release coordinated. The release manager role in these scenarios is typically responsible for:
By providing more powerful tooling, we're able to make individual release managers more effective in their role of orchestrating the releases that are moving through the software development organization. This is in contrast to our Continuous Delivery category vision, which is related but more about the automation that makes automatic, continuous deployment to production possible.
For an example of how this is done in GitLab today, you can see how we managed the 11.4 release at release#462 and release#460. This approach works, but is limited to manual checkboxes to orchestrate the process. This can be significantly improved in several areas, making this process far easier for ourselves and for our users.
Release Orchestration is very much related to Continuous Delivery. To separate them here at GitLab, our Release Orchestration category focuses on the human management of releases, where it is required. This consists of two main points:
We believe Release Orchestration is not a framework for placing limitations on CD teams, but instead a framework for enabling them when operating under more controlled environments, such as large enterprises or those with other regulatory requirements. For these kinds of organizations, even in cases where all development teams are actually doing full CD, there will still be a 'release' where at least feature flags are turned on, press releases happen, and so on.
In order to ensure we strike this balance and don't veer off into the domain of putting the brakes on CD, we will be building Release Orchestration capabilities by growing our existing features rather than going completely off on new tangents. This ensures automation remains the heart of what we do, and is also the right way to learn the most about how to build the right orthogonal solutions, when we eventually get there.
As a company, our priority is to solve problems for the future. We want GitLab to be a solution that brings you to where you want to take your engineering and software delivery processes, rather than propping up inefficient processes with just enough automation to make them bearable. That's why we're starting with solving release orchestration problems from a modern, cloud-native perspective.
That said, we do keep legacy flows in mind as we build, and we're always looking at how we can adapt these cloud-native workflows to also support delivery of more traditional software. What we are being incredibly careful not to do, though, is design software to support legacy problems and adapt those to cloud-native workflows. This is the place that many of our competitors in the space are in, and they struggle due to that challenge.
Security, compliance, control and governance of the release pipeline is handled as part of Release Governance.
Up next we'll be adding an environments dashboard gitlab-ee#3713, giving complete visibility over what's deployed to the environments for your project.
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.
An important view for the way we look at the world is gitlab-ee#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-ce#56024 to automatically manage release notes as part of releases, we can demonstrate how our solution is already capable of doing this.
In terms of sales, a release orchestration dashboard that provides a single view into upcoming releases will be the most impactful: gitlab-ee#3277. This will provide our sales teams with a single, clear view that can easily tell the story about how we solve their release orchestration problems.
This is prospective given the feature is new, but customers typically look for a bit more polish in features like this than the current MVC version provides. Implementing gitlab-ce#65023, 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.)
Alot of interest has been expressed in gitlab-ee#9427, the top vision item below, as a way to improve our own release process.
An exciting item for the vision is the ability to create releases as runbooks via gitlab-ee#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.