How to Create a Good Release Process 🚚
A thorough guide about shipping fast.
Last week I published an article about Scrum, which got an incredible response 🙏
I received so many emails from readers with stories about their dev process, how they tweaked it over time, what worked for them, and what didn’t.
This week’s piece is, in a way, a follow up to last article.
In one of the comments, Kent wondered why teams sometimes work on 2-week cycles instead of—seemingly more natural—1-week ones. Alex and others argued this is sometimes because of lengthy release processes: QA taking days, blocking code reviews, and slow CI/CD.
Of course, that’s not the only source of overhead — you have meetings, context switch, and more — but slow releases are a pain for many teams, and they are one of the key items that separate elite teams from good or average ones.
So, what does a good release process look like?
This is one of my favorite topics, so today I am publishing a comprehensive Guide 📖 that puts together everything I know about it, in a framework that you can use at work. It will be a longer article than usual, with plenty of references to past articles to learn more!
I write one of such guides about once a month. You can learn more about Refactoring Guides below 👇
Here is the agenda for today:
🩺 Shipping is your company’s heartbeat — a reminder of why you should ship fast.
🚚 How teams ship fast — there is no single recipe that works for everybody, but there are a handful of things that the many of the best teams have in common.
📊 Metrics for shipping fast — unlike “productivity” and other murky qualities, you can convincingly measure your release process.
🏁 Where to start? — if you are stuck with releases that take two days, how do you actually improve?
💬 Community Stories — more ideas and insights from expert members of the community.
Let’s dive in!
🩺 Shipping is your company’s heartbeat
I hear many times that the optimal frequency of your releases should depend on your product stage.
As long as you are a small startup, go for it: ship everyday. You have little to lose. But as soon as you have paying customers and higher volumes, take your time. Be thoughtful. Daily releases? Not so fast.
This is one of the biggest fallacies of our industry.
In 2020, Stripe released 3350 new versions of their API. When you factor in holidays and weekends, that’s 10-15 releases per day.
Not only Stripe is well past the startup stage, but we are talking payments here. Is there anything more daunting than having users’ money at stake?
The counterintuitive truth is that, in software, there is no trade-off between speed and stability.
In fact, speed creates a virtuous cycle:
Fast releases → allow for frequent releases
Frequent releases → allow for small releases
Small + fast releases → create lower risk and faster recovery from mistakes.
Of course, this is also good from a product perspective: the more often you release, the more often you get feedback from customers — which in turn enables faster improvements.
Shipping is your company’s heartbeat: it should be just as regular and unremarkable. Conversely, for your engineers, a slow release process is like death from a thousand cuts:
⏲️ Release takes 10 minutes
Feedback loop is good, multiple releases are made every day.
Little context switch during deploy: engineers easily follow through and monitor code in production.
⏳ Release takes 1 hour
Multiple features are batched and released together for convenience.
Failures increase because of batching.
Recovery is slower because of 1) slow deploy and 2) more context switch — engineers move to other tasks while deploying.
More time is spent on QA to avoid disaster
"Only in the morning" releases
🗓️ Release takes 1 day
Deploying becomes a formal process that needs approval.
Only "at start of week"
Dedicated engineering work is needed to maintain the deployment pipeline.
Outages are frequent because releases are large and risky. There is pressure on SREs
🚚 How teams ship fast
So let’s say you are sold on this — but don’t know where to start. How do teams ship that fast?