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.
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).
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.
Which features will be in this release. Negotiated between product, engineering, sometimes other stakeholders.
Order of features. Dependencies between them. What needs to ship before what.
Risky features get more attention: extra review, gradual rollout, kill switches.
Cross-team work: backend changes that frontend depends on; database migrations that require coordinated deploys.
Who needs to know what's shipping when. Customers, support, sales, internal teams.
For continuous teams, the plan is lightweight:
Every 1-2 weeks: what's the team focused on? Loose plan; flexibility expected.
Quarterly direction; not commitments. "Things we plan to ship this quarter."
When a feature requires cross-team work, explicit planning for that feature. Not for everything.
Decouple deploy from release. Code ships continuously; features are released via flag flip when ready. See FeatureToggleManagement.
For fixed-cycle teams, more structure:
Periodic — before each release. Decide scope; sequence; identify risks.
When the release branch is created, scope is locked. New features go to next release.
A period before release where only critical fixes go in. Lets the team stabilize.
Document what's in the release; for customers, support, and internal stakeholders.
Critical issues require shipping outside the cycle. Defined process: branch from release; fix; deploy; merge back.
Some features require multiple teams:
Backend API changes deploy first; frontend deploys after consuming the new API. Dependent on the deploy infrastructure supporting this.
The interim period when both versions of the API exist. Old clients keep working until the migration completes.
For high-stakes cross-team work, weekly sync meetings during the rollout. Once stable, no more meetings needed.
Tools (Jira, Linear, etc.) link cross-team dependencies. Visible to all parties.
Schema migrations, security changes, payment-flow changes, anything customer-facing and visible.
Don't deploy to 100% immediately. Start internal, then small percentage, then ramp.
For risky features, an emergency disable. Tested before launch.
Watch metrics: error rate, latency, business KPIs. Pause or roll back if bad.
Some changes affect everything (auth, core APIs). Others are limited (one feature, one team's customers). Match the rigor to the risk.
Every Tuesday at 10am. Predictable; teams plan around it.
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.
Each feature ships when it's ready. No fixed cadence. Continuous-delivery extreme.
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.
What's shipping; who's affected; what to test. Email, internal blog post, Slack channel.
Release notes; blog posts; in-app announcements for big features. Aligned with marketing for major releases.
Support needs to know what's new before customers ask. Briefings before launch.