Originally posted on the Puppet blog, and republished here with Puppet’s permission.
What is continuous delivery? How is it different from continuous deployment? How does it relate to DevOps? We get these questions a lot, we even created a handbook for continuous delivery.
There are plenty of definitions for continuous delivery; let’s look at the philosophy of author and veteran software engineer Martin Fowler. According to Fowler, you’re doing continuous delivery when:
Your software is deployable throughout its lifecycle.
Your team prioritizes keeping the software deployable over working on new features.
Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them.
You can perform push-button deployments of any version of the software to any environment on demand.
Fowler’s definition is based on the idea that software is created to fill a business or organization’s need, and must be delivered more frequently and reliably so users can enjoy the benefits. Because in today’s world every company relies on software, faster delivery is critical to staying competitive.
Trouble is, trying to speed through traditional waterfall development usually produces late, buggy software. Most developers and IT professionals know this, and are justifiably leery of speeding things up. With traditional methods, they simply aren’t equipped to test software thoroughly enough to release high-quality code.
Continuous delivery works because it incorporates automation, frequent code releases, testing at every stage, and a pull-based architecture that lets only successful releases through. These practices reduce errors and make it easier to improve the software delivery process.
Automation is fundamental to continuous delivery
IT automation lets you make successful processes repeatable. When you decide to introduce a new feature, make a change to a service or system or an adjustment to your infrastructure, automation lets you make the change quickly and safely, without introducing the human errors inherent in manual processes.
Frequent releases are enabled by continuous delivery
Continuous delivery means you’re releasing code frequently, rather than shipping big releases once or twice a year. So you’re testing your new code more often against existing code and systems. There’s less change in each release, so it’s easier to isolate and fix problems. It’s also easier to roll back when needed.
Automated testing is also fundamental to continuous delivery
Automated testing lets you catch errors early and stops you from inadvertently passing bad code to the next stage of development.
Continuous delivery is built on agile practices
Continuous delivery is an outgrowth of the Agile movement. Agile seeks to correct the problem of late, large, buggy software releases by promoting iterative, incremental changes to code and collaboration between teams.
A cultural shift
Continuous delivery requires (and creates) a shift in how people think about work culture. Instead of delivering software every six months to a year, and spending long periods of time fixing things, teams deliver smaller changes more frequently. Problems can be fixed quickly. IT and dev teams agree that creating, testing and deploying quality code is a shared responsibility. Everyone is on the same team.
Continuous delivery works because teams share responsibility for the process, putting an end to siloed teams handing work off to each other. Instead, you’re working together as a single team of people with different skills and responsibilities. Errors and issues become an opportunity to collaborate on improving the process — not an excuse to blame someone else.
Continuous delivery decreases lead times, meaning new features can be delivered faster, since teams don’t have to wait for a semi-annual, big batch release. This has a profound effect on how the product is managed. Product learning is vastly increased, since features are delivered sooner. As the pace of learning increases, product experimentation becomes more reasonable. With rapid learning and safe product experimentation, new innovations are developed faster with a more rapid cadence, leading to greater market competitiveness.
Don’t pursue continuous delivery just so you can deliver faster. Do it because it will make your product better.
Continuous delivery vs. continuous deployment
Many use the terms “continuous delivery” and “continuous deployment” interchangeably, and it’s easy to get them mixed up. Here’s a good way to think about it: Continuous delivery is set of policies that guarantees code can be deployed rapidly. It involves thorough automated testing in production environments, and lets you deploy to users with the push of a button.
Continuous deployment is the next step. Every bit of code that passes the tests is deployed automatically to production. It’s the ultimate goal for any organization that wants to move software faster.
Of course, not every organization can implement continuous deployment. You may have regulations or other business requirements that prevent you from pushing code to the public so quickly, or that require you to deploy only with human intervention, however lightweight that is.
Continuous delivery and DevOps
If you want to implement DevOps practices, continuous delivery is a must. DevOps is all about aligning IT and software delivery with business goals and strategies — and continuous delivery is, too. Once you’re able to practice continuous delivery reliably, your team will have the confidence to know that the the software it pushes out the door is thoroughly tested and and that its intended value is being delivered.