Release Planning

Release planning is the work of coordinating what ships when. For continuous-delivery teams, the plan is largely "what's done is what ships." For teams with fixed release cycles, planning matters more.

This page covers the practices for both modes.

Continuous vs. fixed-cycle releases

Continuous

Code merges to main; main deploys; users get changes within hours or days.

Plans are short-horizon: this week, this sprint. Coordination is mostly through code (merge order, dependencies between PRs).

Fixed cycle

Releases at fixed intervals: weekly, monthly, quarterly. Specific code is in a release branch; new features go to next release.

Plans matter more: which features in which release; what's in scope for v2.5; release branch creation and freeze dates.

Most modern web/cloud teams are continuous. Mobile apps, embedded systems, on-prem software often need fixed cycles.

What planning addresses

Scope

Which features will be in this release. Negotiated between product, engineering, sometimes other stakeholders.

Sequencing

Order of features. Dependencies between them. What needs to ship before what.

Risk management

Risky features get more attention: extra review, gradual rollout, kill switches.

Coordination

Cross-team work: backend changes that frontend depends on; database migrations that require coordinated deploys.

Communication

Who needs to know what's shipping when. Customers, support, sales, internal teams.

Continuous-delivery planning

For continuous teams, the plan is lightweight:

Sprint or iteration planning

Every 1-2 weeks: what's the team focused on? Loose plan; flexibility expected.

Roadmap

Quarterly direction; not commitments. "Things we plan to ship this quarter."

Coordination as needed

When a feature requires cross-team work, explicit planning for that feature. Not for everything.

Feature flags

Decouple deploy from release. Code ships continuously; features are released via flag flip when ready. See [FeatureToggleManagement](FeatureToggleManagement).

Fixed-cycle planning

For fixed-cycle teams, more structure:

Release planning meeting

Periodic — before each release. Decide scope; sequence; identify risks.

Release branch / cut date

When the release branch is created, scope is locked. New features go to next release.

Code freeze

A period before release where only critical fixes go in. Lets the team stabilize.

Release notes

Document what's in the release; for customers, support, and internal stakeholders.

Hotfix process

Critical issues require shipping outside the cycle. Defined process: branch from release; fix; deploy; merge back.

Cross-team coordination

Some features require multiple teams:

Sequenced deploys

Backend API changes deploy first; frontend deploys after consuming the new API. Dependent on the deploy infrastructure supporting this.

Backwards compatibility

The interim period when both versions of the API exist. Old clients keep working until the migration completes.

Coordination meetings

For high-stakes cross-team work, weekly sync meetings during the rollout. Once stable, no more meetings needed.

Dependency tracking

Tools (Jira, Linear, etc.) link cross-team dependencies. Visible to all parties.

Risk management in releases

Identify high-risk features

Schema migrations, security changes, payment-flow changes, anything customer-facing and visible.

Gradual rollout

Don't deploy to 100% immediately. Start internal, then small percentage, then ramp.

Kill switches

For risky features, an emergency disable. Tested before launch.

Monitoring during rollout

Watch metrics: error rate, latency, business KPIs. Pause or roll back if bad.

Blast radius limits

Some changes affect everything (auth, core APIs). Others are limited (one feature, one team's customers). Match the rigor to the risk.

Specific patterns

Calendar-based releases

Every Tuesday at 10am. Predictable; teams plan around it.

Train release model

Like a train: leaves on schedule; what's ready ships; what's not waits for the next one. Common in companies with rapid release cadence.

"Ready when ready"

Each feature ships when it's ready. No fixed cadence. Continuous-delivery extreme.

Major + minor releases

Major (v3.0): big features; communications event. Minor (v3.1, v3.2): incremental improvements.

For products with external users, the major-minor pattern provides predictability.

Communication

Internal

What's shipping; who's affected; what to test. Email, internal blog post, Slack channel.

Customer-facing

Release notes; blog posts; in-app announcements for big features. Aligned with marketing for major releases.

Support team

Support needs to know what's new before customers ask. Briefings before launch.

Common failure patterns

- **Plans that no one consults.** Document exists; doesn't reflect reality.

- **Cross-team work without explicit coordination.** Surprises during integration.

- **Big-bang releases of risky changes.** Bad outcomes affect everyone.

- **No rollback plan.** When things go wrong, no clear path back.

- **Ignoring dependencies.** Frontend ships expecting backend that didn't ship.

- **Communication too late.** Support hears about it from customers.