Release approval workflows for trunk-based continuous-deployment

Question

In trunk-based development with separate production and test/staging environments, and in a GitOps context, what controls can teams apply to ensure rigorous approval processes around promotions of changes between environments?

---

In gitflow DevOps (where there is a long-lived unstable branch from which changes are periodically merged into a stable branch, such that the CI/CD can deploy the unstable branch to a development/staging environment and deploy the stable branch to a production environment) one might use BitBucket or GitHub to apply branch protections to the stable branch (such as requiring multiple approvals and passing tests before merging PRs) while permitting developers to push to the unstable branch with less friction (for more efficient cadence in trialling infracode changes through a real deployment). However, trunk-based workflows have risen in popularity (whereby the promotion process simply involves tagging a release rather than trying to transplant cherry-picked commits onto a diverged history). How can release tagging workflows incorporate similar protections (i.e., multiple approvers and passing tests) while remaining more permissive for other untagged pushes/merges to that trunk branch?

For example, are such (collaborative tag-creation) controls already explicitly featured (in GitHub, BitBucket, or any equivalents), or can it be supported with only modest gymnastics (like enabling general tag protections plus implementing a manually-approved CI action to create a new tag), or would it require external tooling/interfaces run under privileged service accounts (tantamount to a bespoke code management platform)?

Answer 1

The conventional answer is probably to avoid this problem by spinning up (and down) separate test environments for every feature branch, rather than maintaining one perpetual staging environment. In a DevOps context it may take mature/sophisticated Infra-as-Code CI to achieve this and so, instead of strict GitOps, progressive delivery is not uncommonly managed by additional tools such as Flagger or ArgoCD.

There's no established concept of a "Release/Tag Request". Platforms currently seem not to facilitate collaborative release-tagging workflows anywhere near as rigorous as pull requests. A few platforms seem to facilitate restricting tagging to certain principals (sometimes by treating refs/tags/** as though it were a branch), and some seem to permit manual gatekeeping of some CI processes (which might then be delegated to carefully orchestrate releases), but support is generally limited.

Most platforms do support different protection levels for different branches, and PRs between arbitrary branches, so the obvious way to manage separate staging vs production environments under GitOps is still to maintain a stable (or release) branch, and for the promotion workflow to be a PR that merges the main (or develop) branch into stable. The main pitfalls of this gitflow are unintended drift between environments and difficult merges. To avoid drift it is important that any intended persistent differences between environments are represented using separate subdirs and that differences between branches are never allowed to persist after merges. In practice it may warrant a CI script to propose release PRs in a way that ensures those branches end up fully synced.