← Go Back

Release Habits

What are release habits?

Release habits are the repeatable practices a team uses to ship software: what runs before release (e.g. tests, review), how releases are done (e.g. automated deploy, feature flags), and what happens when something goes wrong (e.g. rollback, communication). Good habits make releases routine and low-risk so you can ship often and run experiments (e.g. A/B tests).

Use it when: you want to ship frequently with confidence, support continuous discovery and feedback loops by getting changes out fast, and reduce “release day” stress.

Copy/paste checklist (minimum habits)

  • [ ] Pre-release – Automated tests (and optionally lint, type-check); code review; accessibility and QA as agreed.
  • [ ] Deploy – Repeatable, ideally automated; same path to staging and production.
  • [ ] Rollback – Defined way to revert (e.g. one-click or redeploy previous); known and practised.
  • [ ] Communication – Who’s notified when a release goes out or fails; how users or support are informed if needed.
  • [ ] Post-release – Optional: check metrics or errors; feedback loop from support or monitoring.

Why release habits matter

  • Reduce risk so problems are caught before production or reverted quickly.
  • Make releases routine so the team isn’t blocked by “release fear.”
  • Enable experimentation and A/B testing when you can ship and roll back safely.
  • Support continuous discovery by getting changes to users quickly so you can learn.

What good release habits include

Checklist

  • [ ] Automated where possible – Tests, deploy, rollback so humans aren’t the bottleneck.
  • [ ] Clear quality bar – What must pass before release (tests, review, accessibility checks if applicable).
  • [ ] Rollback practised – Team knows how to roll back and has done it (e.g. in a drill or real incident).
  • [ ] Feature flags or gradual rollout – Optional but useful to limit blast radius and run A/B tests.
  • [ ] Documented – New joiners can follow the same process; no single person is the only one who can release.
  • [ ] Improved over time – Post-incident or retro: what failed, what to change in the process.

Common formats

  • CI/CD: Tests and deploy run on merge or schedule; rollback = redeploy previous artifact.
  • Feature flags: New behaviour behind a flag; release = turn on for a segment or everyone; rollback = turn off.
  • Staged rollout: Deploy to a subset (e.g. 10%) then full; monitor and roll back if needed.

Examples

Example (the realistic one)

Pre-release: Unit and integration tests in CI; PR review required; accessibility checks on key flows in QA. Deploy: Merge to main triggers deploy to staging; manual “promote to production” or scheduled production deploy. Rollback: One-click “rollback to previous” or redeploy last known good. Communication: #releases Slack message; critical issues trigger incident channel. Post-release: Monitor error rate and key metrics for 30 minutes; feedback from support feeds into backlog. The team runs this weekly or on every merge; A/B tests are shipped the same way with flags for variants.

Common pitfalls

  • No rollback plan: “We’ll fix forward.” → Do this instead: Define and practise rollback so it’s fast when you need it.
  • Manual everything: One person runs 10 steps by hand. → Do this instead: Automate tests and deploy; document and share the process.
  • No quality bar: Anything merged gets released. → Do this instead: Define minimum (e.g. tests pass, review done, accessibility on critical paths) and enforce it.
  • Releases are rare and scary: Team avoids releasing. → Do this instead: Ship often with small changes; use feature flags and rollback so releases are routine.
  • No feedback from production: You don’t know if a release broke something. → Do this instead: Monitor errors and key metrics; connect to feedback loop and backlog.
  • Release habits vs QA: QA processes are part of release habits (what you test before release); release habits also cover deploy, rollback, and communication.
  • Release habits vs continuous delivery: Continuous delivery is the goal (ship whenever you’re ready); release habits are the practices that make it safe and repeatable.
  • Release habits vs experimentation: Experimentation and A/B testing depend on being able to ship and roll back; release habits enable that.

Next step

Document your current release steps (pre-release, deploy, rollback, communication). Identify one gap (e.g. no rollback drill, or no automation) and fix it. If you run A/B tests, ensure your habits support shipping and rolling back variants safely.

Related Terms