I’m a technologist turned into a word person. For those of you who know me, I started as a developer, learned ops and security as it was needed, and eventually my love of talking about technology lead me to writing, tech marketing and evangelism. I still develop, though; I can’t stop that—it’s kind of a part of me.
But as a technologist at heart, words are a way to convey concepts, and any that don’t contribute to the conversation in a meaningful way aren’t necessary.
So it is pretty weird for me to be saying, “What if we renamed CD?” But I think there is a real point here that we could address. If you look across the industry, you will find quotes (and in IT departments, the reality) that for most of us, CD is not about continuous deployment. It is about continuous delivery and on-demand deployment. Unfortunately, “on-demand deployment” makes a pretty terrible acronym in the English-speaking world, so perhaps we should use “on-demand update.” Deployment is looking at it from the application’s perspective, but as DevOps, we get to look at it from both perspectives and we are updating the server(s) to run our application(s). So on-demand update (ODU) would work, but I’d be open to alternatives.
In this case, the wording change is useful. There are a few organizations with very special needs that do actual continuous deployment. No one else does. The ability to say, “OK, we’ve got enough together and tested to warrant the disruption this will cause. Update the app,” is what most organizations use CD for. And I think that’s right. While purists will roll their eyes and talk about the advantages of each bug fix, no matter how small, rolling out in a timely manner, most orgs aren’t going to do 15 updates a day. And orgs that like stability don’t want to. Testing doesn’t resolve every issue; otherwise, we wouldn’t need things like Bugzilla for anything in production, risking introduction of new ones 15 times a day. That’s just not on the list of priorities for most organizations, particularly if their CI system is on longer run-times.
So I like CI/CD/ODU. Then you are separating continuous delivery and on-demand deployment, which I would argue is a huge piece of the problem. I’ll quote Georg von Sperling of CA Technologies during the Q&A section of a webinar:
Continuous delivery does not equate continuous deployment to production. If I may be so bold, I would state continuous delivery is a practice to allow deployment to production at any time with a high degree of quality and a low amount of risk with zero downtime and zero touch. A business leader recently said to me that whereas, in the past, ‘Deployment to production was an IT decision, it is now a business decision at a push of a button.’ But, CD certainly played a part in this paradigm shift, as the entire delivery process, including testing, is visible and predictable.
Which makes sense, once explained, but it’s truly a source of confusion in the field, so separating the two makes sense. The point is to communicate clearly, and requiring a further clarification of what exactly CD is says we’re not communicating clearly at all. Indeed, delivery and deployment definitions that are meaningful to IT are close enough in context as to automatically cause the confusion when a single “CD” is presented.
So even though I don’t get terribly wrapped up in wording, I think this is a worthwhile change to consider. Words convey meaning; let’s ensure the meaning they convey is clear.
For those of you knee-deep in CI/CD, yes I am aware of Fowler’s definitions, but this clears up the fact that he has to explain how continuous delivery is different from continuous deployment in the definition for continuous delivery.
In short, we’re being confusing. Stop it. Let’s talk about tools/technologies/methodologies to get there, not keep clarifying confusing terminology.
