Release Preparation Pipeline

Twenty-one days, five gates, one irreversible afternoon

46 issues across five phases, day 0 to day 21. The deploy is day 14 — one afternoon out of three weeks. Everything before it exists to make that afternoon boring. Everything after it exists because sometimes it isn’t.

Why the freeze and the rollback come before the deploy

• Freeze at day 2, QA starts day 4. The branch is cut and the freeze announced in #engineering the same day. You cannot regression-test a moving target, and every cherry-pick after the branch invalidates a run that already passed.
• Rollback is verified on staging at day 12 — two days before the deploy, one day before go/no-go. A rollback plan that has never been executed is a hypothesis, and day 14 is the wrong time to test one. It shares day 12 with the deployment runbook and both belong to @devops, so the path in and the path out get written together.
• Snapshot before migrations. Both land on day 14, in that order. A migration run against a database with no snapshot turns rollback from a procedure into a data-recovery project, and no feature flag saves you from a schema change.
• Second regression pass at day 10. Critical bugs are fixed at day 9, then every fix is re-verified against the full suite. Those fixes are the least-tested code in the release, so they get treated like new code.
• Customers hear at day 17, not day 14. Error rates are watched for four hours at day 15, performance compared against baseline, hotfixes ship at day 17. The announcement goes out after you know it held.

Who owns which gate

The most important thing about the eleven handles is what @release_lead does not own. The release lead runs the pipeline and triages the aftermath; the go/no-go at day 13 belongs to @eng_manager. Whoever has spent two weeks pushing a release toward a date is the worst-placed person to decide it should slip.

• @qa_team — regression, integration, smoke tests, and the critical flows after deploy. @dev_team fixes; @qa_team decides whether the fix counts.
• @security — the OWASP scan at day 6, its own gate rather than a checkbox inside QA.
• @devops — branch, runbook, rollback rehearsal, snapshot, migrations, deploy, flags, tag. The role with the fewest reversible steps.
• @sre_team — the first four hours after go-live, held apart from the people who deployed. Reading your own error rates at the end of a deploy day is not observation, it is hope.
• @product_manager — UAT sign-off at day 8 and the release notes. @docs_team, @marketing and @support carry the parts a customer touches.

How the dates resolve

[Due + 14d] is an offset, not a stored date. Smart Replace groups every offset written against the same Jira date field, you pick one anchor, and the rest resolve from it — so slipping a release by three days means editing one value, not 45. Saved in the template editor that anchor becomes a named date variable. Units run d, w, m, bd; this tree ships calendar days, and bd counts Monday to Friday instead, which is what you want when day 14 would land on a Saturday. Skip holidays walks a resolved date past public and bank holidays for a chosen region — date variables in Jira issue templates has the full behaviour. The handles here are roles, not people; to spread a block of work across whoever is free, round-robin assignment distributes it in rotation.

What breaks if you skip one

• No staging rollback rehearsal. The rollback gets invented at 02:00 with the incident channel watching, and rollbacks written under pressure skip the database.
• No snapshot. You restore old code onto a new schema and turn a bad deploy into an outage with no exit.
• No second regression pass. Your fix for the P1 is the cause of the P2, and you hear about it from a customer.
• No UAT sign-off. At day 15 you find that what shipped is not what was asked for — a product decision to unwind, not an engineering one.
• No four-hour watch. The spike that justified a rollback in hour one becomes a week of support tickets by hour forty.

Five people, or fifty

At fifty, eleven handles are eleven people and this tree is a coordination contract. At five there is no release manager and no SRE rotation: @release_lead, @devops, @sre_team and @dev_team are one person, who wrote the code, approved the deploy and is now on call for it.

The cost is specific. Go/no-go stops being a decision, because the only candidate is the person who wants to ship. Nobody independent verifies the rollback. The four-hour watch is run by someone twelve hours into their day. Keep three things: give go/no-go to someone who did not write the code, even if that is the PM; rehearse the rollback on staging; take the snapshot. Collapse the rest — docs, marketing and support into one comms task, the readiness review into a fifteen-minute call, the retro into a written paragraph.