On this page

Ship often enough and the release stops being an event. That is the whole lesson. It took me 225 of them to fully believe it.

These were not 225 deploys of the same app. Client platforms, SaaS products, my own projects. .NET services, Rust backends, mobile releases with store review in the loop. Different stacks, same pattern. The teams that shipped calmly all did the same handful of things. The teams that dreaded release day all skipped the same handful of things.

🔗1) Small batches

Every painful release I have seen had one trait in common: too much changed at once. Three weeks of features, a migration, and a config change, all going out on a Friday afternoon.

The fix is boring. Make releases small enough that any single one is uneventful. Small diffs are reviewable, revertable, and debuggable. If a release needs a war room, the batch was too big. Not the team.

🔗2) The checklist is the process

Release discipline lives in a checklist, not in someone's head. Ours is short:

  • What changed, in one paragraph
  • How to verify it in production
  • How to roll it back, and how long that takes
  • Who is watching, and for how long

If rollback takes more than ten minutes to explain, fix the pipeline before shipping the next feature.

🔗3) Automate the toil first

Nobody ever regretted automating versioning, changelogs, artifact publishing, or environment promotion. Pure toil. Zero judgment required, real attention consumed, every single release.

My order: build, test, version, publish, deploy to staging, deploy to production. Manual gates survive only where a human decision is actually required. Everything else is a script waiting to be written.

🔗4) Staging should look like production

"Works in staging" means nothing if staging doesn't look like production. Same data shapes. Same scale characteristics. Same third-party behavior. The cheapest staging improvement I know is replaying real production traffic patterns against it.

Where I can't have a true twin, I use feature flags and canary deploys, and let production be the test environment for a small, watched slice of traffic. With a kill switch.

🔗5) Track four numbers

After every release: how long the deploy took, how long until we confirmed it was healthy, whether rollback was needed, and how long rollback took. Teams that track these get faster. Teams that don't keep arguing about whether releases are "getting better."

🔗6) Write the changelog for your future self

Your future self, at 2 AM, bisecting a regression. A changelog entry says what changed, why, and what to check. "Fixes" is not a changelog entry.

🔗7) No surprises on release day

No unrehearsed migrations. No config changes bundled "while we're at it." No first-time-ever steps. Anything novel gets done on a quiet Tuesday, verified, and then becomes part of the checklist.

🔗Next step

Most release pain is not a tooling problem. It is a batch-size problem and a discipline problem. Tools amplify whatever habits the team already has.

If your team dreads release day, that is fixable. Usually faster than expected.