Deploy gates & approvals

Change control without a ticket queue.

Not every deploy should be automatic. A deploy gate is a deliberate checkpoint — a required approval, a manual trigger, an environment restriction — between a green pipeline and a production release. In GitLab this is protected environments plus a manual rule; in GitOps it is a reviewed merge to the state repo, optionally with a sync window or manual sync. Either way the point is the same: production changes are intentional, reviewed, and recorded.

deploy-prod:
  stage: deploy-prod
  environment: { name: production }   # protected: only maintainers, approval required
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual                     # a human decides when to release
  # GitLab records who triggered it and when — change evidence, no ticket system needed

Change control you get for free

A protected environment with required approvals gives you an audit trail per production deploy — who approved, who triggered, at what time, tied to which commit and pipeline. That is change management without a separate ticketing tool bolted on: the evidence auditors and incident reviews want is already captured by the pipeline. The gate is both a safety control (a second person looks before prod) and a compliance one (a record exists).

Gates that check, not just ask

The strongest gates verify something, not just prompt a human. Require that the image signature verifies before deploy; require that all scanning stages passed; require the SLSA provenance matches the expected source. These turn "someone clicked approve" into "the artifact provably meets policy," and they can be automated so the gate is consistent rather than dependent on an approver remembering to check. Human approval plus automated verification is the belt-and-braces production gate.