Release Governance includes features such as deploy-time security controls to ensure only trusted container images are deployed on Kubernetes Engine, and more broadly includes all the assurances and evidence collection that are necessary for you to trust the changes you're delivering. For example, having a strong integration with CI/CD system to ensure artifact chain of custody and traceability all the way to commit, assurance of test completion, quality gates, auditing, and any other governance requirements are enforced in the release.
In the end, people want tools that isolate areas they should have access to; you shouldn't have to have admin access in order to get your job done. Also, things like the CI/CD tool should not have root everywhere. Container security, secrets management, API gateways; people need help with navigating these solutions.
Up next is binary authorization, a key part of &762. This will be delivered via three components:
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.
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 (which adds manual approval jobs/gates to the GitLab pipeline) will help us perform better for analysts and the kinds of customers who are approaching release management from a more top-down perspective.
Similarly, integrations with technologies like ServiceNow (gitlab-ee#8373) will help GitLab fit in better with larger enterprise governance workflows.
The CS team 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 an explicit approval job to handle approvals in release workflows.
gitlab-ce#21583 has been requested by the delivery team / @marin to allow for more secure, locked down access to production-type environments instead of relying on more broad project permissions.
Very much 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.
Blackout periods (gitlab-ce#51738) will help compliance teams enforce periods where production needs to remain stable/not change.