# Release checklist for teams shipping AI-written code

> Copy this list into your release ticket for each release. Replace [brackets], delete steps that don't apply, and delete this note.

- **Release:** [version or name]
- **Release owner:** [name]
- **Planned date:** [YYYY-MM-DD]
- **Ticket or notes:** [link]

## 1. Before the cut

- [ ] Every change in the release is merged through a pull request with an approval from someone other than its author.
- [ ] Every AI-assisted change in the release says so in its pull request, with the tool and the task.
- [ ] No change in the release has an open finding of [high] severity or above.
- [ ] Changes to pipelines, infrastructure, authentication and migrations were approved by their code owners.
- [ ] Feature flags for unfinished work are off by default in production.
- [ ] Release notes are drafted from the merged pull requests, not from memory.

## 2. Release candidate

- [ ] The full test suite passed on the release commit itself, not on an earlier one.
- [ ] Coverage is at or above the floor of [N]% for [the modules that have one].
- [ ] The SBOM for the release commit is generated and reviewed (see the SBOM review checklist).
- [ ] No dependency in the SBOM is under a license on the [disallowed license list].
- [ ] No known vulnerability of [high] severity or above in the dependencies, or each one has a written exception.
- [ ] Secrets scanning passed on the whole release diff.
- [ ] Database migrations ran against a copy of production data, and their run time is known.
- [ ] The candidate ran in [staging] for at least [N hours] with no new errors.

## 3. Deploy

- [ ] The rollback plan is written down: revert the commit, turn off a flag, or roll back the deployment. The person who will do it knows it.
- [ ] Migrations that can't be reversed are called out, with the plan if they go wrong.
- [ ] The deploy is announced in [channel], with the release owner reachable for [the next N hours].
- [ ] The deploy goes out the same way as every other one, through the pipeline. No manual changes on servers.
- [ ] Health checks and the key dashboards are open while it rolls out.

## 4. After the deploy

- [ ] Error rates and latency are back to normal within [N minutes].
- [ ] The main user journeys work in production: [sign-in], [checkout], [the feature you shipped].
- [ ] Release notes are published.
- [ ] Anything that went wrong is written up, and an incident caused by an AI-assisted change gets a postmortem that names the review step or gate that should have caught it.
- [ ] Evidence for the release is stored: the commit, the approvals, the test runs, the SBOM and the deploy log.

## Sign-off

| Step              | Signed by | Date         | Notes |
| ----------------- | --------- | ------------ | ----- |
| Before the cut    | [name]    | [YYYY-MM-DD] |       |
| Release candidate | [name]    | [YYYY-MM-DD] |       |
| Deploy            | [name]    | [YYYY-MM-DD] |       |
| After the deploy  | [name]    | [YYYY-MM-DD] |       |

---

From https://aicodeops.dev/templates/release-checklist · Last updated 2026-10-24 · Licensed CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)