A release checklist for payment code works well when most items are enforced by the repository rather than remembered by people. Require reviews and checks on the release branch, gate production with an approved deployment, record what shipped, and rehearse the way back before you need it.
Automate what you can enforce
GitHub rulesets let you require status checks before merging, require deployments to succeed in a named environment first, block force pushes, and require signed commits. GitHub environments add required reviewers, self-review prevention, wait timers and branch limits. Each item you put in a rule is an item nobody can forget on a busy day.
| Checklist item | Enforced by |
|---|---|
| Change came through a pull request | Ruleset requiring pull requests |
| A different person approved it | Required approvals and code owner review |
| Tests and security checks passed | Required status checks |
| History cannot be rewritten | Block force pushes rule |
| Deployed and verified in staging first | Rule requiring deployments to succeed in an environment |
| Production deploy approved by a person | Environment with required reviewers and self-review blocked |
| Just the release branch can deploy | Environment deployment branch rule |
The GitHub documentation describes each of these. The block force pushes rule notes that force pushes can delete branches or point a branch at commits that were never approved in a pull request, which is why it matters for a release branch.
Items that need a human
Some items cannot be enforced by a setting. Add these to the pull request template:
- Does this change touch money movement, authorization or key handling? If yes, name the owner reviewers.
- Are there database migrations? Describe the order and whether they can be reversed.
- What is the rollback plan, and who runs it?
- Which dashboards or alerts will show a problem in the first hour?
- Is the release window appropriate for your payment volumes?
These questions are our suggestions. The intent is that a person writes the answer down before shipping.
A staged release flow
- Merge to the main branch through a protected pull request.
- A pipeline builds an artifact and runs tests and dependency checks.
- The pipeline deploys to staging, which the ruleset can require before merge.
- A production deployment job waits in the protected environment. Reviewers see the change summary.
- After approval, optional wait timer elapses, then the deploy proceeds.
- A post deploy check confirms health and key payment metrics.
- The release record captures commit, approver, time and result.
Rehearse the way back
A rollback plan that has never run is a guess. Practice reverting a deployment in staging, including database changes. For schema changes, prefer steps that work with both old and new code so a rollback does not require a data repair under pressure.
Keep an emergency path that is honest
Sometimes you need to ship a fix quickly. Define in advance what is allowed: for example one approver instead of two, with the other review done afterwards. If you let administrators bypass rules, GitHub's environment settings let you choose whether they can, so decide deliberately and record each use.
Review the checklist itself
After each release that had a surprise, ask which checklist item or rule would have caught it, and add it. Remove items nobody uses, since long lists get skimmed.
Where Safeguard fits
Safeguard's policies and gates add vulnerability and dependency checks to the pull request stage, and its compliance and evidence automation can keep dated records of results. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the gate and note which checks must pass before a release branch accepts a change.
Quick check
Should a hotfix skip the checklist?
Define a shorter emergency path in advance, and record each use. Skipping silently erodes the control.
Which controls are automated?
Pull request requirement, approvals, status checks, force push blocking and deployment approval can all be enforced by repository and environment settings.
Sources
Last reviewed: 19 October 2026.
