Benefits of Frequent Delivery

Oftentimes I'll meet with teams and they'll talk about their delivery cadence, their deployment cadence. They'll say, we release, we deliver quarterly. We do quarterly releases. And when I ask why, their answer oftentimes is, well, we're risk averse. It's interesting to think about the idea of being risk averse and then doing something so infrequently that you can't get good at it. If you're doing something just three or four times a year, you're not going to be very good at it. Let's just face it. And by the way, the technology landscape changes so much in that time that you'll have to learn how to do it differently. You'll have to learn every time. Instead, what if we did continuous delivery? We foster collaboration through continuous delivery. The practice of continuous delivery is centered on efforts around automation and improvements. It involves promotion of software between environments and rapid responses, reliable and repeatable manners, and allows for end users to receive value on a regular basis with lower risk and reduced overhead and cost for each deployment. You might be wondering why I would say reduced risk. Well, The State of DevOps report shows that clients that are delivering more frequently are actually finding their environments are more stable. Their mean time to recovery is actually reduced. They're able to keep their environments up, which may be a little counterintuitive, especially if you're only doing quarterly releases. It may seem like, well, that was so difficult. I don't want to do that very often. Well, smaller batches can help with this quite a bit. I like to call that limiting the blast radius. Checking in and releasing 100 lines of code limits the blast radius. How much could go wrong? How much could you break? Don't forget, we've got all of our deployment pipeline automated, so we're continually regression testing as we go. So we should be continually automating and, and deploying. I talk about this reducing costs, and that's true. But make no mistake, there is a pretty heavy investment in the infrastructure needed to do continuous delivery. To get to sort of, you know, we're delivering every second or so or every minute. You've got to have some pretty robust infrastructure. Now the costs have come down with cloud infrastructure and of course our ability to have infrastructure as code. Those things have helped for sure. But there's still, there's an investment. And so you need to do a sort of customer cost benefit analysis. Do you need to deploy as frequently as Netflix or Amazon or Google or Microsoft maybe? I don't know what business you're in. But find that balance. Teams use tools to automate continuous and repeatable delivery to any environment. Testing activities are incorporated into the deployment pipeline. Changes are incorporated into the delivery process frequently in small batches and smoke tests run following deployment automatically to ensure that that the app is running and available. Now those smoke tests, those are done in production. When I say continuous delivery, I mean in production. Continuous integration typically is lower level environment stuff. But I'm referring to production. We're always referring to production. So what are some of the benefits? Software delivery is executed on demand with low risk and little drama. We want go live to be a sort of non event. Oh, we already went live. It was Tuesday at 10am like we want to get away from the go live weekends where everybody's know working over the weekend and things are going crazy. Like we want to move away from that should be a non event, no drama. Some other benefits include quality is built into the delivery process from the initial iteration. Costs are lower based on less troubleshooting of defects and issues with deployments, and then the sort of long arduous integration and regression testing cycle. Those can be eliminated or at least reduced as automation is brought in. A number of folks will tell me, well, we don't need to deliver that frequently. Our customers don't want to have that much change. That's fine. What I want us to think about is sort of decoupling the idea of deployment from release. Okay, so what does that even mean? Well, think about it this way. Oftentimes when I say deployment or continuous deployment, people are thinking that those changes are going to be released to the user to interact with at the same time. That doesn't have to be the case. You can batch those releases up to whatever cadence makes sense for you, for your client, for your customer. But getting in the practice of deploying continuously will help reveal a number of different things and bring all the benefits. The premier example of this was was Facebook Messenger. Facebook released messenger into production and had it out in production running for. They would say it too long but had it out in production where they could, they could test it, they could smoke test. It just wasn't released. So they had deployed but not released. They decouple deployment from release and you can use feature toggles for this. There's a common technique, it's called feature toggling. To decouple deployment from release. I want you to get in the habit of thinking how soon can we get to production? Here's a technique you can use right away with your teams. Consider deploying something that is nothing. What if you deployed a single line break on a webpage? Just add a, you know, add a line break there. What if you updated comments in your code and packaged that up and then deployed to production? Deploy something that is nothing to production. In doing this, you'll reveal all of the pipeline problems that you might not even have known existed. You might find that there's a group of people that need to approve changes that you didn't know about. You might find that to get to production, it actually takes two more steps than you thought. So as soon as possible, you want to be deploying to prod. And I would say deploy something that is nothing to test that it will reveal quickly what your deployment pipeline needs. So continuous deployment. Get in the habit of deploying continually, not necessarily releasing continually.