The business case for continuous delivery

Originally posted on the Puppet blog, and republished here with Puppet’s permission.

We’re often so focused on crafting code that we forget the reason why: to deliver a better experience for our users and help our business grow. Let’s take a step back and look at how continuous delivery can help your organization reach its goals. And when you’re done here, make sure to get even more details on continuous delivery in the full ebook.

Continuous delivery means low-risk deployments

Continuous delivery, once processes are in place and regularly used, gives you the option of much faster software development cycles. Instead of releasing code once or twice a year, companies doing continuous delivery have the option of releasing multiple times per day. When you’re releasing at that rate, each release is small — maybe only a single line of code — so the risk to system stability and customer service is much lower. Every change is easier to roll back, easier to test — and if there’s a failure, easier to diagnose. A company still may not want to release new code as multiple times per day, but what really matters is that every piece of code that’s checked in is proven and ready to deploy.

This makes it much more viable to continually test small changes on your systems and on your customers. For example, you might want to see if a big blue “buy now” button on the homepage makes people act more quickly than your existing green button. With continuous delivery practices in place, you can test that change to see if it breaks anything before rolling it out. And you can limit the change to just a small percentage of website visitors to see how they respond, or see if visitors arriving at various times of day, or on different days of the week, react any differently. The feedback from these experiments helps business managers make better decisions.

Continuous delivery means faster market response time

Markets change all the time: Regulations get modified, commodity prices go up and down, safety warnings go out, celebrities launch fads. With faster cycle times, you can respond much more quickly to those changes.

Something you thought was profitable may turn out to be a loser. Website analytics may show that people visiting your site on mobile devices are buying more than those using desktop computers. Whatever decision you need to make, you can implement it faster if you’re already practicing continuous delivery.

Once the whole organization gets comfortable with making more changes more often, you’ll have a distinct edge over competitors whose deployments are infrequent, chaotic and error-prone. And the more you practice frequent code release, the better you get at it.

Continuous delivery means happier, more productive staff

Workplace satisfaction matters. There are just too many options out there for talented technology people; they don’t have to stick around if they’re getting burned out. Continuous delivery is known to reduce stress on technical teams, ending the 2:00 a.m. pager calls and reducing the last-minute technical fixes that add to technical debt and slow future releases. With continuous delivery, employees can perform at higher levels.

Puppet’s 2016 State of DevOps Report found that high performers have better employee loyalty, as measured by employee Net Promoter Score (eNPS). Employees in high-performing organizations were 2.2 times more likely to recommend their organization to a friend as a great place to work, and 1.8 times more likely to recommend their team to a friend as a great working environment. Other studies have shown that this is correlated with better business outcomes.

Continuous delivery also fixes another source of developer dissatisfaction: writing code that never gets released. It’s not at all uncommon for blocked development pipelines to swallow code forever, and no developer likes working on a product that no one ever gets to use. Bonus: When there’s less stress, there’s more room to be creative. Technical teams who aren’t fighting fires and fixing bugs all the time have the bandwidth to innovate in ways that benefit the business.

Make a positive cultural shift with continuous delivery

Don’t forget continuous delivery is as much a cultural shift as it is a technical one. For most teams, the biggest shift is from separate teams dealing with the writing, testing and deployment of software to a single team that is responsible for the successful deployment of quality software — albeit one staffed by people who have specialized skills and are tasked with specific responsibilities.

Developers will still write code, QA people will still manage testing, and IT operations will still configure and manage infrastructure, but everyone shares ownership of the software development and release process. That means when something goes wrong, it’s important to refrain from finger-pointing. Instead, get the delivery pipeline moving again, and then analyze the situation for a blameless postmortem. The object: to treat each such event as an opportunity to learn and make the process better.

Continuous delivery requires that testing and IT operations people get involved earlier in the software design process. When all parties talk over what the new application will need, in terms of validation and infrastructure, the IT and testing people will be better prepared to test and deploy, and developers will be better equipped to make sure the code they write is testable and deployable.

When it comes time to deploy, most errors will have (hopefully) been worked out already. If there are errors, each deployment should be a small enough change that it’s easy to roll back to the last known good state.

Want to learn more? Download Puppet’s Continuous Delivery eBook, and read the 2016 State of DevOps Report to learn why DevOps is critical to continuous delivery.