The quickie guide to continuous delivery in DevOps

In today's world, you have to develop and deliver almost in the same breath. Here's a quick guide to help you figure out which continuous delivery concepts will help you breathe easy, and which are only hot air.

Developers are always under pressure to produce more and release software faster, which encourages the adoption of new concepts and tools. But confusing buzzwords obfuscate real technology and business benefits, particularly when a vendor has something to sell. That makes it hard to determine what works best—for real, not just as a marketing phrase—in the continuous flow of build and deliver processes. This article gives you the basics of continuous delivery to help you sort it all out.

To start with, the terms apply to different parts of the same production arc, each of which are automated to different degrees:

  • Continuous integration means frequently merging code into a central repository. "Frequently" means usually several times a day. Each merge triggers an automated "build and test" instance, a process sometimes called continuous build. But by either name, continuous integration and continuous build do nothing in terms of delivery or deployment. They're about code management, not what happens to the code afterward.
  • Continuous delivery refers to the automation of the software release process, which includes some hands-on effort by developers. Usually, developers approve or initiate the deployment, though there can be other manual steps as well.
  • Continuous deployment is continuous delivery with no manual steps for developers. The whole thing is automated, and it requires not so much as a nod from humans.

With continuous deployment, "a developer's job typically ends at reviewing a pull request from a teammate and merging it to the master branch," explains Marko Anastasov in a blog post. "A continuous integration/continuous deployment service takes over from there by running all tests and deploying the code to production, while keeping the team informed about [the] outcome of every important event."

However, knowing the terms and their definitions isn't enough to help you determine when and where it is best to use each. Because, of course, every shop is different.

It would be great if the market clearly distinguished between concepts and tools and their uses, as they do with terms like DevOps. Oh, wait.

"DevOps is a concept, an idea, a life philosophy," says Gottfried Sehringer, chief marketing officer at XebiaLabs, a software delivery automation company. "It's not really a process or a toolset, or a technology."

But, alas, industry terms are rarely spelled out that succinctly. Nor are they followed with hints and tips on how and when to use them. Hence this guide, which aims to help you learn when to use what.

Choose your accelerator according to your need for speed

But wait! Isn't speed the key to all software development? These days, companies routinely require their developers to update or add features once per day, week, or month. This was unheard of back in the day, even in the era of agile software development.

That's not the end of it; some businesses push for software updates to be faster still. "If you work for Amazon, it might be every few seconds," says Sehringer.

Even if you're a deity of software bug-squashing, how can you—or any developer or operations specialist—deliver high-quality, "don't break anything" code when you have to build and release that fast? Everyone has their own magic bullet. "Agile!" cries one crowd. "Continuous build!" yells another. "Continuous integration!" cheers a third.

Let's just cut to the chase on all that, shall we?

"Just think of continuous as ‘automated,'" says Nate Berent-Spillson, senior delivery director at Nexient, a software services provider. "Automation is driving down cost and the time to develop and deploy."

Well, frack, why don't people just say automation?

Add to the idea of automation the concepts of continuous build, continuous delivery, continuous everything, which are central to DevOps, and we find ourselves talking in circles. So, let's get right to sorting all that out.

The 1-2-3 of automated DevOps

Continuous build means "build it in small steps." And given that there are small steps, each is in the direction of an ongoing process—i.e., integrating software continuously into production.

The label "continuous integration" often is used for the same thing, though some practitioners make a distinction. Continuous build is a part of continuous integration, a process wherein developers write code, merge it with existing code in the repository, and then rely on automation to take over to build and test the now-integrated code. This frees developers to spend more time on writing code and innovating, instead of time sinks such as manual compilation and testing.

But just because some of the work is automated doesn't mean it's actually faster. For one thing, it hasn't been deployed. The deployment process may be manual and long—or delayed until busy developers can get around to it.

Unsure how to get started with containers? There's a guide for that.

"With continuous integration in place, an organization can shift from a mind-set and process around monolithic, heavyweight application upgrades to an approach that enables and encourages small and frequent changes," explains Dan Juengst, principal technology evangelist at OutSystems, a rapid application delivery platform for enterprise mobile and web apps.

Continuous build is more of a concurrent step than an isolated one in the larger continuous integration march, however. "It represents the constant check-in and build approach of continuous integration, whereas continuous delivery is really about creating a sustainable, low-risk approach to deploy your application code," says Susan W. Sparks, chief transformation officer at InfoZen, a provider of agile software development, DevOps, and cloud migration services.

The premise is that your code is always in a deployable state, says Sparks: "You achieve that continuous delivery state through continuous integration."

Put your innovative teams up front. "The move to continuous integration is typically one of the first steps in the DevOps adoption process," says former Yahoo CIO Mike Kail, now chief technology officer at Cybric, an application and code security-as-a-service provider. "This creates a much more collaborative environment for developers, which usually increases code quality." 

When to use continuous integration vs. application release automation

So, does that mean continuous integration and application release automation (ARA) are two names for the same thing? Nope, says Sparks; they're two separate components within an overall framework.

Continuous integration centers on application developers who use common source code libraries (such as GitHub). Each time developers update the software, their code is reintegrated into the overall application, Sparks says. In other words, the continuous integration tool checks out all the source code, builds everything (such as compiling the software), runs all the unit tests, and reports with immediate feedback.

ARA, on the other hand, is the packaging of the integrated code and the subsequent automated movement of the code through a development lifecycle.

"As an example, the code starts in development," Sparks says. "When all features are complete and all unit testing is complete, you would then use your application release automation to move that code package to the next environment, such as a test environment." 

Looking at it from another angle: "Continuous integration equals content, and application release automation equals tooling and processes," says Sehringer. "They are different sides of the same thing."

Rinse. Repeat, repeat, repeat, repeat (the point of automation in DevOps)

Automation has obvious returns on investment. "You can make sure it's good in pre-production and push it immediately to production without breaking anything, and then just repeat, repeat, repeat, over and over again," says Sehringer.

In other words, you move delivery through all the steps in a structured, repeatable, automated way to reduce risk and increase the speed of releases and updates.

In an ideal world, you would push a button to release every few seconds," Sehringer says. But this is not an ideal world, and so people plug up the process along the way.

A company may need approval for an application change from its legal department. "Some companies are heavily regulated and may need additional gates to ensure compliance," notes Sehringer. "It's important to understand where these bottlenecks are." The ARA software should improve efficiencies and ensure the application is released or updated on schedule.

"Developers are more familiar with continuous integration," he says. "Application release automation is more recent and thus less understood."

Wrapping it all up and tying it with a bow

First, understand the commitment, what's at stake, and what you're aiming to achieve.

"Continuous build, continuous integration, and continuous delivery should be the bare minimum," says Berent-Spillson. "Continuous deployment is a much bigger step."

"With continuous deployment, you're committing to deploying every new line of code without having a human involved in that process, other than a final click to send it out the door," he adds. "When new code is committed to the repository, it's built, integrated, tested, and staged automatically. The bigger change here is the commitment to mainline development."

Varying degrees of automation is what distinguishes these concepts, but they all fit in the larger development framework. The overarching process looks like this: continuous integration, then continuous delivery or continuous deployment. Think of continuous deployment as continuous delivery on steroids. But there is nothing to deploy until the code is integrated, built, and tested, which is why continuous integration comes first.

The best advice for putting these concepts into practice, experts say, is to start small and improve something in every cycle. Work your way up until you're no longer focused on point problems but have formed the structure necessary to capture speed and safety through automation.

"Start with continuous build, then commit to automated testing, the test pyramid, and start doing continuous integration. As you get more comfortable with your continuous integration and improve your automated deployment, make sure your rollback is as seamless," advises Berent-Spillson.

This method makes continuous deployment easier because rolling back becomes much simpler, he says. "At the point where you get a failure, you roll back and then ask yourself, 'What could we have automated, instrumented, or tested to prevent that issue from happening?'"

Lessons for leaders

  • If all you're doing is continuous build and continuous integration, you're likely creating bottlenecks and slowing the deployment process. The goal is to ship often, and you're going to need more automation to push releases faster.
  • Automate or improve something in every cycle until you finally reach full automation status. Make a list or a map so that your efforts move you steadily ahead.
  • Use continuous delivery next, after continuous integration. Only after you have worked out compliance and governance issues in continuous delivery, and made your rollbacks seamless, should you try to move to continuous deployment. Continuous deployment is touchless automation for software release.