Deployment gate
A check or human approval that must pass before a release can move to the next environment or reach production.
What it is
A deployment gate is a blocking condition between a release and its next environment. It can be an automated test, a security scan, an error-budget check, or a named person's approval. The release proceeds only when the condition passes. GitHub Environments can hold a production job for required reviewers, while the workflow's earlier jobs supply the machine checks.
Reach for a gate before a costly or hard-to-reverse step: production, a database migration, an app-store submission, or a regulated change. A good gate has a clear owner, a fast answer, and an explicit record of what passed or who approved it.
Gotcha: vague gates become ceremony. 'QA signoff' means little if nobody knows which build was tested or what evidence counts. Bind the gate to an immutable artifact, name the exact checks, set a timeout, and define whether a failure blocks, retries, or rolls back.
Ask AI for it
Add a production deployment gate to GitHub Actions. Create a GitHub Environment named production with required reviewers, then make the deploy-production job use environment: production and depend on exact lint, typecheck, test, build, and staging-smoke job names. Attach the commit SHA and immutable artifact digest to the approval summary, set a 30-minute job timeout, prevent concurrent production deploys, and fail closed if any required check is missing. Record the approver, check results, artifact digest, and deployment URL in the workflow summary.