01 · Release contract & branching template

Document version v2026100501 · Two layers: a mandatory delivery contract with SRE, and a recommended branching template that teams may adopt, adapt or ignore. · interactive original ↗

Part A — Delivery contract (mandatory)

1. One Release Manager per repo per release, however many teams or departments contribute. The Release Manager integrates all MRs and release details for the repo and is SRE's only contact. For a release across repos, their Release Managers agree one release plan (repos, order, version to revert to).
2. Deadline: tag + full commit hash + release plan reach SRE by the end of the working day before release day (D-1). Later → next release day.
3. One tag per repo per release day. All MRs are merged before the tag is created.
4. Release day: gray (real traffic) runs from 11:00 to 14:00, any number of rounds, each with the whole set. A problem in any repo → SRE withdraws the whole release from gray; every Release Manager re-delivers tag + hash and the whole set goes through gray again. Gray ends at 14:00 — a round still running is stopped, and a release that has not passed moves to the next release day. A set that passed gray goes to production in release-plan order (may run after 14:00).
5. Tag ↔ hash check before deploying; a mismatch is not deployed.
6. Revertible or behind a toggle, stated in the request. If neither, SRE still deploys and the development team fixes forward.
7. Rollback: SRE redeploys each repo's previous version in reverse release-plan order (whole release at once), or switches the toggle off. Releasing again the same day is the Release Managers' decision; the whole set is re-delivered and must pass gray by 14:00.
8. Hotfix only for customer-complaint incidents, accounting/payment problems, or performance fixes. Requested by the Release Manager with evidence, confirmed by SRE, delivered as tag + hash, gray then production.
9. Boundary: version-control mistakes inside a repo (wrong tag, wrong starting point, merge mistakes) belong to the development team. SRE deploys what was delivered.

Roles

Role	Layer	Responsible for
Release Manager (Dev)	contract	One per repo per release; integrates MRs and release details; delivers tag + hash on D-1; requests hotfixes and config-only deploys.
SRE	contract	Tag ↔ hash check; gray then production; withdraws from gray; rollback; hotfix eligibility; freeze periods. Does not merge, branch or tag in app repos.
Developer, Dev Lead	template	Development, review and what goes in, inside the team.
QC	template	Optional future step: acceptance of an rc before delivery.

Part B — Branching template (recommended)

Figure 3 — Branch lines: release/1.4.0 is cut before D-1 and takes in two teams’ features; rc.1 is delivered on D-1 and fails in gray, so the whole release is withdrawn; the fix becomes rc.2, re-delivered and passing gray before 14:00, and goes to production; a later hotfix is cut from master, merged into the release, and rc.3 goes through gray to production; once every repo is verified, the Release Manager merges the release into master and creates v1.4.0.

• feat/* from master; release/X.Y.Z cut from master before D-1; shipping features merged in via MR; the Release Manager creates vX.Y.Z-rc.N and delivers it.
• A gray failure is fixed on the original feat/*, merged again, and a new rc is re-delivered; it must pass gray by 14:00.
• After production is verified, the Release Manager merges release/X.Y.Z into master and creates the release tag vX.Y.Z.
• Hotfix branching: Case A (release in production, not yet merged) — hotfix/* from master, MR into the release, new rc. Case B — rc on the hotfix branch, merged into master after production.
• No cherry-pick; squash only for feat/* or hotfix/* → release/*. Feature toggles let a feature be switched on later with a config-only deploy.