(This is part four of a four-part series. Read parts one, two, and three here.)

This is it, folks: the final chapter in our epic trek through the history of DevOps! Last time, we talked about how the Agile movement gave rise to the more defensive practices of automated testing and continuous integration. This time, we’ll be discussing the progression of that theme with continuous delivery and continuous deployment.

Admittedly, the introduction of two more “continuous” terms is a bit confusing, especially because the lines between one term and the next are so blurry; it doesn’t help that they are recent developments and could be renamed at any moment.

But fear not! We’re well-equipped to deal with this kind of volatility and will tread carefully. At this point in our saga, “history” is hardly even the right word for what we’re discussing. What we’re really talking are current events, which is very exciting but also much squishier than more concrete subjects like waterfall development or Agile methodology. Enough throat-clearing, off we go!

Continuous Delivery

Think back to that time when we explained what continuous integration was. We talked a lot about the advantages of constantly merging bits of code — all in the name of avoiding enormous code conflicts at the end of a development cycle. People were excited to reap the rewards of this methodology and eagerly boarded the continuous integration train.

But the train didn’t always cross the border between developers and operators. Developers washed their hands of code they pushed to production, safe in the knowledge that it was “someone else’s problem”. Operators anticipated changes from the other side with dread, trembling at the horrors lobbed over the wall.

siege.jpg A group of developers prepares to deploy as operators race to defend themselves.

It didn’t matter that developers were coming together to merge their code before releasing it; customers still couldn’t actually use anything if it hadn’t been released. In this way, there was still some very real distance between what the developers made and “the real world”, and no one was minding the gap.

But in 2010, Jez Humble and David Farley released a book called Continuous Delivery, where they proposed an extension of continuous integration. They argued: “Software that’s been successfully integrated into a mainline code stream still isn’t software that’s out in production doing its job.” In other words, it doesn’t matter how fast you assemble your product if it’s just going to sit in a warehouse for months.

Continuous delivery is the practice of ensuring that software is always ready to be deployed. Part of that insurance is testing every change you’ve made (a.k.a. continuous integration). In addition, you’ve also made the effort to package up the actual artifacts that are going to be deployed — perhaps you’ve already deployed those artifacts to a staging environment.

So continuous delivery actually requires continuous integration. It relies on the same underlying principles: cutting work into small chunks and carefully titrating the flow of product to your users. But, to quote the CTO of my own company, “software that isn’t ready to deploy is dangerous”; you should always be prepared to send your code out into the world, like a college student.

indiana.jpeg The government’s “top men” are not good at continuously delivering.

Developers + Operators = DevOps

DevOps is the mashup of development and operation. It’s the crossover episode, the sodium chloride; the fusion of all that is good with both worlds. It’s not a piece of software; it’s not a process — it’s not even really a word. It’s a cultural movement that rests on an argument: code isn’t really serving its purpose until it’s been delivered. This is something that both developers and operators can agree on.

Another thing they can agree on is that the reason code isn’t delivered is because of fear. “It’s not ready,” mutters a Reasonable Operator. “Why not?!” the developer shouts, a vein pulsing in their forehead. “Well,” explains the Reasonable Operator, “it’s a big change. We’re going to need to make sure it doesn’t screw anything up.”

This operator is indeed quite reasonable. The developer is afflicted with a self-inflicted disease, which I like to call doing too much work. Developers do this because they like making amazing things, and complex things are more amazing than simple things. And they build tolerance to their own projects: engineers need to build increasingly sophisticated systems in order to get that coveted rush of satisfaction and fulfillment. But big changes mean big risks — these are the bane of operational stability. Developers, too, recognize the inherent problems of pushing too much code at once: it’s harder to find bugs in huge haystacks of code.

Without continuous delivery, developers and operators are equally stressed by the same thing — the act of deploying. And the purpose of continuous delivery is to make the act of deploying so painless that no one notices. How many times did you blink while reading this blog post? That’s right, you don’t know because it doesn’t hurt when you blink.

That is the whole point of continuous delivery. This reduction in friction is what brings developers and operators together. It’s a healthier kind of MAD (mutually assured deploys), and one that tempers the once-raging tempers of both parties. DevOps is the symbolic merging of two archetypes that were once throttling each other’s throats.

Continuous Deployment

“So how far can we take this continuous thing? What else could we automate?” Great question, dear reader! And thank you for paying attention!

Even in the wonderful world of Continuous Delivery, changes are still manually approved before launching into the choppy waters of Reality Ocean! But: if you’ve truly done your homework and created a robust testing framework, imagine the exhilaration of automatically pushing your code out to sea whenever the tests pass!

Nautical metaphors aside, we’ve been stressing that big changes require small changes. So if developers actually committed to committing small changes, there (theoretically) shouldn’t be much harm in automatically deploying changes that pass all tests. In other words, if every deploy is already a tire fire, a smaller tire fire will be easier to extinguish.

The first official DevOps gathering was an enormous success.

Continuous deployment might seem extreme and dangerous. And in its purest form, it is — which is why it really only exists as an abstract concept. Very few companies can practice proper continuous deployment because it’s hard to pull off. Teams usually need some amount of breathing room between development and deploys, especially for sensitive changes like database migrations.

Continuous deployment also encourages other kinds of continuous action, like analytics, error-reporting, and testing. Rollbar ties code changes to error frequency and key organizational metrics. PagerDuty shares the operations load across the team and makes error resolution a little less hectic. LaunchDarkly champions feature flags to incrementally test and ship value.

Overall, there really aren’t many technical differences separating continuous delivery from continuous deployment; it’s more a matter of culture and mindset. Those in the deployment camp just happen to be a little more comfortable with regularly stepping off precipices — because they know that there’s another precipice just below them.

If they fall, it’s not going to be that far.

It’s the Future

There’s a reason you haven’t seen very many dates in this chapter. And it’s because these changes are happening right now. Sure, there are leaders spearheading the movement and companies offering these sorts of services to make the continuous transition more continuous.

If you find all these continuous methodologies hard to tell apart, that’s fine. At a high level, they can all happily live under the umbrella term of “DevOps”. Together, they reflect a trend towards agility, speed, and a grand reduction in feedback loops between maker and consumer. Yes, I just linked to my own piece again, but go read it anyway.

This “Brief History” has turned out to be not so brief. And it’s not done yet, which means we can’t sew the events of these chapters into a nice quilt, lay it on a bed, and be done with it. No, this has been a recap of The Story Thus Far and, like most things in our industry, it will be out of date in a few short months.

There are two ways to respond to this world of constant flux: you can stick your head in the sand and hope the changes disappear. Or you can lean in, abandon your perfectionism, and thrive. As the wall between developers and operators crumbles further, these groups will learn lessons from one another: developers will think about performant code, and operators will grease the wheels of deployment.

It’s impossible to predict the future, so focus on understanding the present. This is the belief behind the DevOps movement, the monitoring services, the constant shipping. it’s quickly becoming the way to effect meaningful change. This brief history is ongoing, and everyone has a chance to become an author.

“I know that my apprehensions might never be allayed, and so I close, realizing that perhaps, the ending has not yet been written.”

— Atrus, commenting on the DevOps movement. From the game Myst (1993).