.svg)
Deployment frequency is very important. In fact, it's usually the first place the teams start. And what you're doing is you're measuring how many times you change production. So the goal of delivering code quickly to production is to ship as many times as possible. In order to make that work, you need to change the batch size to be as small as possible. So in other words, ship as few changes to production at a time, as you can.
A common misconception of deploy frequency is that by shipping code to production more often, you're actually creating more risk because the thinking goes that if a certain percentage of my changes to production fail or cause an incident, then if I do it more, then I'm going to have more incidences. But counterintuitively, it works the exact opposite way, which is the more you're changing production, with smaller changes, the better understood each of those changes are. And when those changes are understood and they're small in scope, the risk of those going bad is less.
So think about it this way. If I shift a bunch of changes at once and something goes wrong, which one of those changes caused it? We have no idea. There's so many. Maybe it has 10, 20, 100 developers involved. But if I'm shipping a code one change by one, if one of those things fail we know exactly what caused it, the developer's around, and then they can fix it. So by changing your batch size to be as small as possible and shipping as often as possible, you're actually reducing your overall risk.
So technically what you want to do here, is you want to ship each [inaudible 00:01:42] request or individual change to production at a time. That works great for smaller teams, but it doesn't always work for a bigger team. So for example, if you're a big team on say a monolith, what you want to do is a technique called release train, where you ship to production in fixed intervals throughout the day. So again, your goal is to minimize the batch size as much possible to reduce your overall risk and increase your deployment frequency. So again, ship more, smaller.
.svg)
.svg)
Go from zero to one hundred deploys a day.
.webp)
What is Deployment Frequency?
Deployment frequency is very important. In fact, it's usually the first place the teams start. And what you're doing is you're measuring how many times you change production. So the goal of delivering code quickly to production is to ship as many times as possible. In order to make that work, you need to change the batch size to be as small as possible. So in other words, ship as few changes to production at a time, as you can.
A common misconception of deploy frequency is that by shipping code to production more often, you're actually creating more risk because the thinking goes that if a certain percentage of my changes to production fail or cause an incident, then if I do it more, then I'm going to have more incidences. But counterintuitively, it works the exact opposite way, which is the more you're changing production, with smaller changes, the better understood each of those changes are. And when those changes are understood and they're small in scope, the risk of those going bad is less.
So think about it this way. If I shift a bunch of changes at once and something goes wrong, which one of those changes caused it? We have no idea. There's so many. Maybe it has 10, 20, 100 developers involved. But if I'm shipping a code one change by one, if one of those things fail we know exactly what caused it, the developer's around, and then they can fix it. So by changing your batch size to be as small as possible and shipping as often as possible, you're actually reducing your overall risk.
So technically what you want to do here, is you want to ship each [inaudible 00:01:42] request or individual change to production at a time. That works great for smaller teams, but it doesn't always work for a bigger team. So for example, if you're a big team on say a monolith, what you want to do is a technique called release train, where you ship to production in fixed intervals throughout the day. So again, your goal is to minimize the batch size as much possible to reduce your overall risk and increase your deployment frequency. So again, ship more, smaller.
Go from zero to one hundred deploys a day.
