Good DevOps, Part 3: Continuous Delivery and Deployment
In the second blog in this series on DevOps, you’ve learned what continuous integration (CI) is and how it benefits an organization. The ability to commit code and have it built in a centralized location that all developers are committing to is the key to getting the code ready to use.
But CI is just the beginning. How do you deploy the software to perform further testing, and finally deploy it to a production environment? That’s where continuous delivery and continuous deployment come into play.
Think about the last time you had to deploy software to an environment. It’s never as easy as just installing software. There are always different packages to install, configuration items to remember, and so on. Even with a document playbook, we’re human and make mistakes. And these mistakes are compounded by the increased frequency of software updates these days.
To eliminate those errors, you need to take the next step in automation and apply continuous delivery.
For example, let’s say you’re a server admin and a developer shows you the location of a new web application running in Internet Information Services (IIS) on a Windows server. A typical IIS web application requires IIS applications, application pools, binding, SSL certificates, and more. To increase efficiency, you take the next step in automation and create a script for all these things. That’s good, but you still have to run that script manually.
Using continuous delivery, you could leverage that automation code you wrote and integrate it directly into the CI pipeline. This ensures the required configuration is applied to a server. The integration saves time for both you and the developer, who doesn’t need to request a manual deployment.
The continuous delivery process takes the extra step and perhaps deploys the code to a testing environment, making it available for someone else to perform other tests on.
Continuous deployment is similar to continuous delivery. Continuous deployment takes the next and final step of deploying code to an environment. Continuous delivery, on the other hand, gets the code up to that point and waits for approval. In continuous deployment, the entire process is performed automatically in a continuous deployment pipeline, with no approvals whatsoever.
There might be a schedule in place, or perhaps the deployment is done immediately. The automated deployment process can occur in any environment, including a testing or production environment.
Code testing is one of the most important aspects of continuous deployment apart from automating application delivery. Automated testing confirms the difference between deploying an application with or without bugs. A bug can easily take down a production system if it’s not tested before deployment.
A perfect implementation of continuous deployment happens when the process is trusted and there are no occurring issues like a system crash during deployment. Trust is a huge factor in a continuous deployment pipeline.
Delivery vs. Deployment
At this point, you may be wondering what the differences are between continuous deployment and continuous delivery. From an automation perspective, the processes are nearly identical.
Think about the two processes in terms of delivering a package to your door. You can think of continuous delivery as when the mailman drops off the package. The mailman won’t go into your house, of course, but you’re not getting value from that package until it enters. You’re not allowing the package to come in until you approve it.
Continuous deployment, on the other hand, is allowing the mailman to open your door, set the package inside your house and leave. The package has been delivered to its final destination (inside your house).
Sounds simple, right? But this difference is rarely simple in the real world. For an organization to go from continuous delivery to continuous deployment requires a well-developed culture of monitoring, on-call support, and having the ability to recover an environment quickly.
And the culture doesn’t have to do with just one team—every team has responsibility for this. Continuous deployment requires everyone—front-end devs, back-end devs, infrastructure, cloud engineering, and every other IT team—to be on top of how the application is integrated into an automated process. You can’t just throw some automation code into a pipeline and call it a day.
Continuous deployment is the last step in the CI/CD journey. If an organization trusts the process, it will eventually strive to attain 100% automation. However, because of the thorough requirements to ensure an application’s resiliency and the planning that must go into the process ahead of time, many organizations choose to stay at the continuous delivery step.
Enjoy the DevOps Journey
Both continuous delivery and continuous deployment help complete the journey to automating an app’s entire deployment process. Each is a phase of an automation process that builds upon the last.
Which process an organization follows depends not only on the tools, but also trust. To achieve full automation of an important software application, organizations must trust the teams and the process, and continually learn. They must decide how far they’re willing to go to deliver value to their customers.
More automation is always a good thing, but it has an upfront cost in terms of planning, team collaboration and trust. If you’re ready to pay that price, you’ll find the benefits more than worth it.