DevOps is more about culture than tools or technology. When it comes to the various tools and technologies, though, Continuous Deployment is the ultimate goal–the star around which all of the other “continuous” solutions revolve.
I wrote about the role of Continuous Deployment in DevOps in this blog post:
One of the promises of DevOps is continuous deployment. DevOps is, first and foremost, a matter of shifting the traditional business culture more than the tools and technologies that enable it. Once that culture exists, though, one of the defining aspects of DevOps is automation and continuity.
Earlier this year I wrote about the seeming ubiquity of “continuous” solutions throughout DevOps:
“If DevOps is the buzzword du jour for tech, then continuous is the buzzword du jour of DevOps. Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response…or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.”
Taking a closer look at all of that continuous continuousness, however, continuous deployment stands out as one of the prevailing goals of effective DevOps. Continuous integration, continuous delivery and the other continuous tools and processes are all in some way related to facilitating the flow of continuous deployment or monitoring and managing it after the fact—which ultimately feeds back to the beginning of the loop and back to continuous deployment.
Chris Riley tried to muddle through the confusion of continuous integration, continuous delivery and continuous deployment. In his explanation of continuous deployment, he stressed the impact of this symbiotic loop that surrounds it: “Continuous deployment has additional costs, as it relies on instrumentation, to ensure that new functionality does not result in bugs and also on infrastructure that allows effortlessly backing out new features when a defect has not been caught by automated tests.”
I defer to Riley on most things, but I don’t agree with his summation that everyone should do continuous integration, some should do continuous delivery, but only the rare few should strive for continuous deployment.
I guess it depends on what perspective you’re considering it from. From the standpoint of ease or simplicity and the likelihood that an organization can execute it effectively I can see where Riley is coming from. From the point of view of the goal of embracing DevOps, though, I would reverse his order and say that everyone should do continuous deployment, most should implement continuous delivery to facilitate it, and some (or maybe most as well) should adopt continuous integration to drive continuous delivery.
Read the complete post on DevOps.com: Continuous Deployment is king of the DevOps hill.
- Tackling Swivel Chair Syndrome - November 14, 2024
- Unlocking Proactive Compliance with Adobe’s Common Controls Framework - October 14, 2024
- Unlocking the Power of Continuous Threat Exposure Management - October 8, 2024
Tony,
Great post. Let me dig a little deeper into CI. Delivery and Deployment imply a very specific type of application. And the reality is that most organizations do not have such applications. CD is the poster child of DevOps but likely not a reality. And in most CD flows integration environments are a crucial pieces anyway. Which means most of the time even CD based environments have CI as part of their architecture.
The market education has taught many that you have to be doing CD to be doing DevOps. While CI is, both in process and how it is implemented, very similar to CD. It is a safer and easer place for organizations to start. So i’m not talking about how CI works. I’m talking about how realistic it is for an organization to adopt it. And unless you are doing purely LOB development or LOB integration development, you can leverage and benefit from CI environments. While if you have an established delivery chain you can’t simply move to a process where code goes directly to production.