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 to achieve this as a natural byproduct of your way of working within GitLab and not requiring any additional effort or attention needed in order to prepare for compliance and audit tracking.
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 our first feature that is part for evidence collection for SDLC gitlab#26019. We will start by adding a snapshot of the metadata of the release to the release page, in order to know if and what has been tampered with. It is important to know everything that happens in your software delivery pipeline. We want to make it easy to answer: what, where, when, and by whom any change in the software happened, without any additional effort, by making this data accessible from the release itself.
In addition, we have been challenged by monitoring the deployment of merge requests to different environments internally, and want to solve this problem for us and for customers alike gitlab-infra#477. Another obstacle that we need to overcome internally is using an external environment for deployment, while still having the need to monitor it's activity for compliance and governance gitlab#22513.
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#26019 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#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#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#8373.
gitlab-org#9187 is the most upvoted item and adds a way to validate approvals in release workflows.
gitlab#15778, 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#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#24295) will help compliance teams enforce periods where production needs to remain stable/not change.