Everyone's scrambling to migrate from their legacy Jenkins or TeamCity setups to something like GitHub Actions or GitLab CI, and the sales pitches always focus on the shiny "as-code" part. Fine. But nobody talks about the operational glue that holds these processes together, especially the human gates.
In the old GUI system, you had a button. A big, fat, permissioned button that said "Deploy to Prod." Some manager or senior engineer had to physically click it. The audit trail was "Bob clicked it at 3 PM." Moving this to a declarative pipeline isn't just a syntax translation; it's a cultural and procedural transplant. The new system wants you to define the approval *logic* in YAML, but the *authority* and *notification* mechanisms are suddenly your problem.
So you're left cobbling together a Rube Goldberg machine of environment protection rules, required reviewers in pull requests, and Slack webhooks that ping a channel where people just ignore them. Or worse, you hard-code a list of GitHub usernames in your pipeline file, which is outdated the next time there's a re-org. The old GUI system, for all its faults, often had a dedicated, centralized, and visible approval queue. The new paradigm scatters the pieces.
How are you all handling this without just recreating the same monolithic bottleneck or, conversely, creating an approval process so porous it's meaningless? Specifically, how do you manage the secret sauce: the list of *who* can approve, the *notification* that an approval is needed (that actually gets seen), and a clear *audit log* that doesn't require grepping through JSON API logs? I've seen teams try to use the PR review system for this, but that conflates code review with operational approval, which are different concerns. I've also seen the "wait for a workflow_dispatch" manual trigger pattern, which just gives you a different button in a different GUI. Feels like we're just moving the furniture around.
Anecdotes aren't data.
That's such a good point about the cultural transplant. I'm new to setting up pipelines, and I just assumed the approval part would be built-in somewhere. You're saying we have to stitch together three different systems (the pipeline, the permissions, and the notification) just to replace one button click?
So, practically speaking, where does the actual approval decision live then? If Bob isn't clicking a button in the CI/CD tool anymore, is he approving a pull request, replying to a Slack message, or clicking something in a separate dashboard tool? That seems messy.