release-management

# Release Management (Deep Workflow) Releases combine **coordination** and **risk management**: what ships, when, how we verify, and how we recover. ## When to Offer This Workflow **Trigger conditions:** - Scheduled or train-based releases; need predictable cadence - Hotfix chaos or unclear ownership - SemVer vs calendar versioning debates **Initial offer:** Use **six stages**: (1) versioning policy, (2) branching & tags, (3) release candidate & checklist, (4) communication, (5) deploy & verify, (6) post-release & hotfixes). Confirm deployment model (continuous delivery vs batch releases). --- ## Stage 1: Versioning Policy **Goal:** Define SemVer (or alternative) rules: what counts as breaking, how migrations are communicated, and how pre-releases work. **Exit condition:** Written policy linking version numbers to customer-facing risk. --- ## Stage 2: Branching & Tags **Goal:** Choose a strategy (trunk-based with release branches, GitFlow-lite, etc.) and use **annotated tags** tied to changelog entries. --- ## Stage 3: Release Candidate & Checklist **Goal:** Freeze criteria: QA scope, DB migrations dry-run, feature flag defaults, config diffs, load/perf smoke for risky changes. --- ## Stage 4: Communication **Goal:** Internal notes for support/CS/SRE; external release notes with **breaking** changes highlighted and migration steps. --- ## Stage 5: Deploy & Verify **Goal:** Canary or progressive rollout where possible; SLO dashboards; **rollback trigger** agreed before deploy starts. --- ## Stage 6: Post-Release & Hotfixes **Goal:** Lightweight retro; hotfix branches from the release tag; forward-merge fixes back to main; track incidents linked to release. --- ## Final Review Checklist - [ ] Versioning and changelog reflect risk - [ ] Branch/tag strategy is team-wide consensus - [ ] Checklist covers migrations, flags, QA, and comms - [ ] Rollback plan rehearsed or documented - [ ] Hotfix process defined ## Tips for Effective Guidance - Smallest releasable increment reduces blast radius. - Coordinate DB schema changes with expand/contract patterns when zero-downtime matters. - Complement with **ci-cd** and **changelog-authoring** skills for tooling depth. ## Handling Deviations - **SaaS with heavy feature-flagging:** “release” may be continuous—still document communication and flag cleanup discipline.