Release Policies

The Hook (The "Byte-Sized" Intro)

"Who released that?" "When was v2.3 deployed?" "Can I ship today?" Without release policies, every release is ad-hoc — some land on Friday at 5pm, some never get tagged, some skip testing. A release policy answers these questions before they're asked: who, when, how, and what happens if it fails.

📖 What are Release Policies?

Documented rules governing how, when, and by whom software releases are created, deployed, and rolled back.

Conceptual Clarity

A release policy covers:

Area	Question It Answers	Example
Cadence	How often do we release?	Weekly on Tuesday
Freeze window	When do we NOT release?	No deploys Friday-Sunday
Authority	Who can trigger a release?	Team lead or on-call
Checklist	What must be done before release?	Tests pass, changelog updated
Rollback plan	What if it breaks?	Revert within 15 minutes
Communication	How do we announce?	Slack + release notes

Release cadence options:

Cadence	Pros	Cons
Continuous	Fastest delivery	Needs robust automation
Daily	Predictable, fast	Needs daily attention
Weekly	Balanced	Changes batch up
Sprint-based	Aligns with agile	May be too infrequent
Manual	Full control	Slow, error-prone

Real-Life Analogy

A release policy is like a restaurant's opening schedule. Customers know when you're open (release cadence), what to expect (quality checks), and what happens if the kitchen catches fire (rollback plan).

Visual Architecture

flowchart LR CODE["Code Ready"] --> CHECKLIST["✅ Release Checklist"] CHECKLIST --> WINDOW["📅 Release Window"] WINDOW --> DEPLOY["🚀 Deploy"] DEPLOY --> MONITOR["👀 Monitor"] MONITOR -->|"Issue"| ROLLBACK["⏪ Rollback"] style DEPLOY fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb style ROLLBACK fill:#2d1b1b,stroke:#e94560,color:#e94560

Why It Matters

Predictability: Everyone knows when releases happen.
Safety: Freeze windows prevent risky Friday deploys.
Accountability: Clear authority prevents "who shipped that?"
Recovery: Pre-planned rollback reduces incident response time.

Code

markdown

# ─── Example Release Policy (in CONTRIBUTING.md) ───

## Release Policy

### Cadence
- Production releases: **every Tuesday at 10am UTC**
- Hotfixes: **anytime, with on-call approval**

### Freeze Windows
- No deploys **Friday 3pm** through **Monday 9am**
- No deploys during **company events or holidays**

### Pre-Release Checklist
- [ ] All CI checks pass on `main`
- [ ] Changelog updated
- [ ] Version bumped (SemVer)
- [ ] Tagged with `v{version}`
- [ ] Release notes published
- [ ] Rollback tested in staging

### Rollback Plan
1. Revert the release tag: `git revert HEAD`
2. Deploy previous version: `git checkout v{previous}`
3. Notify #incidents channel
4. Post-mortem within 48 hours

### Authority
- Regular releases: any team lead
- Hotfixes: on-call engineer + team lead approval

Key Takeaways

Define cadence, freeze windows, checklists, and rollback plans.
No deploys on Fridays — give yourself a business day to fix issues.
Document the policy in CONTRIBUTING.md — everyone can find it.
Rollback plans should be practiced, not just documented.

Interview Prep

Q: What should a release policy include? A: Release cadence, freeze windows, pre-release checklist, authority (who can release), rollback plan, and communication channels. Document it in CONTRIBUTING.md.
Q: Why do many teams avoid deploying on Fridays? A: If a deployment breaks something, the team has limited time to fix it before the weekend. Issues discovered on Saturday may go unnoticed until Monday, expanding the impact.
Q: What is a release freeze window? A: A time period where no deployments are allowed — typically weekends, holidays, and company events. It reduces risk by ensuring incidents happen during business hours when the team is available.