Release Governance is all about the controls and automation (security, compliance, or otherwise) that ensure your releases are managed in an auditable and trackable way, in order to meet the need of the business to understand what is changing.
This includes features like having a strong integration with CI/CD to ensure an auditable chain of custody for artifacts and traceability all the way back to the commits and issues that made up the release, confirming requirements such as test completion or other quality and security gates, appropriate approvals are gathered in the process, and so on. Our intention is not to implement this through heavy manual controls, but in a DevOps first way where these are achieved as a natural byproduct of your way of working within GitLab.
Related to this topic, but complex enough to be its own category, is secrets management.
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.
Up next is waiting for approvals as part of the release pipeline (gitlab-ee#9187), which is our MVC iteration for solving approvals in GitLab. An ask we receive quite frequently from our enterprise customers is the ability to enforce that someone approved a change. We do allow for collecting approvals at the MR level, but we don't enforce this requirement for pipelines. By adding a check for MR approval at deploy-time, we offer a lot of flexibility about how teams want to implement their approval process, but do it in a way that is natural for working within GitLab and does not impede continuous delivery (as opposed to, for example, adding a manual job that requests approval from someone in real time.)
This category is currently at the "Planned" maturity level, and our next maturity target is Viable (see our definitions of maturity levels). Key deliverables to achieve this are:
A key capability of products which securely manage releases is to collect evidence associated with releases in a secure way. gitlab-ce#56030 introduces a new kind of entity that is part of a release, which contains various kinds of evidence (test results, security scans, etc.) that were collected as part of a release generation. Collecting this data and surfacing it in a clear way for auditors is a great differentiator for GitLab, and one that is uniquely enabled for us by being a single application for the DevOps lifecycle.
The analysts in this space tend to focus a lot right now on existing, more legacy style deployment workflows so changes like gitlab-ee#9187 (better support for validation of approvals in the pipeline) will help us perform better here, as well as for the kinds of customers who are really need a bit more control over their delivery process.
Similarly, integrations with technologies like ServiceNow (gitlab-ee#8373) will help GitLab fit in better with larger, pre-existing enterprise governance workflows.
The CS team frequently sees requests for integration with ServiceNow for change management built in to CD pipelines, as per gitlab-ee#8373.
gitlab-ee#9187 is the most upvoted item and adds a way to validate approvals in release workflows.
gitlab-ce#21583, which implements user access controls for environments, has been requested by our own delivery team to allow for more secure, locked down access to production-type environments instead of relying on more broad-based project permissions.
Important for this category (though also expansive and includes a few others) is our epic for locking down the path to production, which will help us successfully deliver compliance controls within the software delivery pipeline.
Also related to locking down the path to production is binary authorization (gitlab-ee#7268) which provides a secure means to validate deployable containers. At the moment however this only works with GKE so ultimate user adoption is limited. As such we're keeping an eye on adoption, but have not yet implemented an MVC.
Blackout periods (gitlab-ce#51738) will help compliance teams enforce periods where production needs to remain stable/not change.