Goal
Every release has a number, contents, an approver and a way back — so you always know exactly what is running and can roll back in minutes.
Inputs → outputs
Inputs
- UAT acceptance certificate
- Test and security reports
- Change list from git
Deliverables
- Release notes + CHANGELOG
- Tagged release with checksum / signature
- Release approval record
- Tested roll-back plan and commands
Teams & roles
- DevOps / SREpackaging, tagging, roll-back
- Project Management / Scrum Masterrelease schedule, notes, approval meeting
- Quality Assurance (QA/QC)confirms release quality
- Engineering (FE · BE · Mobile)feature flags, technical CHANGELOG
- Support & Customer Successuser communication and support readiness
- Client (Product Owner / sponsor)approves contents and timing
RACI matrix
R — does the work · A — accountable, final sign-off (exactly one A per activity) · C — consulted before · I — informed after.
| Activity | PM | Dev | QA | Sec | Ops | CS | Client |
|---|---|---|---|---|---|---|---|
| Version numbering & tagging | · | R | · | · | A | · | · |
| Release notes & CHANGELOG | A | R | · | · | · | C | · |
| Packaging & keeping the roll-back version | · | · | · | C | A | · | · |
| Feature flags & progressive enablement | C | A | · | · | · | · | C |
| Release go/no-go | A | · | R | C | C | · | C |
| Roll-back rehearsal | · | · | R | · | A | · | · |
PM = Project Management / Scrum Master; Dev = Engineering (FE · BE · Mobile); QA = Quality Assurance (QA/QC); Sec = Application Security (AppSec); Ops = DevOps / SRE; CS = Support & Customer Success; Client = Client (Product Owner / sponsor)
Quality gate
Release approval signed; previous version kept for roll-back; release notes sent.
Entry criteria
- Acceptance (full or milestone) signed
- No release-blocking defects
Exit criteria
- Version consistent across git tag, image / installer and release notes
- Previous version kept and roll-back commands tested
- Database migrations backward-compatible or with a restore script
- Release approval record signed
- Release announcement sent
Activities
- 1.Version with SemVer; tag git to match the build
- 2.Write user-facing release notes and a technical CHANGELOG
- 3.Package an immutable release (container image / signed installer), keep the previous one for roll-back
- 4.Put new features behind feature flags to separate "deploy" from "release"
- 5.Release go/no-go: testing, security, acceptance, migrations, roll-back plan
- 6.Rehearse roll-back and define when it is mandatory
Checklist
Tick to self-review — 0/6. Ticks stay in this browser only and are not sent anywhere.
Document templates
Markdown (.md) files: open in any editor, or paste into Word / Google Docs. Each states its purpose, who fills it in and when.
Client involvement
- Approve release contents and timing
- Notify end users
Tools
- Git tag / GitHub Releases
- Container registry (GHCR)
- Feature flag (OpenFeature)
- CHANGELOG.md
Reference standards
- Semantic Versioning 2.0.0
- MAJOR.MINOR.PATCH — bump MAJOR on breaking changes
- Keep a Changelog 1.1.0
- Human-readable changelog convention
- ITIL® 4 — Release management · Deployment management
- Two distinct practices: releasing value to users and moving changes into environments
- OpenFeature (CNCF)
- Open, vendor-neutral specification for feature-flag APIs
- DORA metrics
- Change failure rate and time to restore
Common pitfalls
- Bumping the version by hand and never releasing it
- Two builds overwriting the same version number
- Irreversible migrations without a plan
- Feature flags left forever as technical debt
Real example
cuongthai.com (desktop app), 19–20 Aug 2026: one version number was bumped but never released, and another was built twice, the second overwriting the first. Releases now go through ONE command: check the branch, require a clean tree, block while another build runs, refuse already-published versions, and re-check the auto-update files after the build.
Where to learn
Subjects and courses on cuongthai.com that teach this stage’s work.