You are here

DevOps and continuous delivery: Joined at the hip

public://pictures/Juan C Perez photo1.jpg
Juan Carlos Perez, Writer, Freelance

The VP of IT and the CIO had been having a fine morning. In fact, they'd been having a fine past couple of years—until a few minutes ago, when the CEO abruptly pushed the C-suite's panic button and their blood pressure shot up to the stratosphere. The CEO has just learned that their main competitor pulled an Amazon and revamped its software development and delivery process in a way that lets them deploy bug patches, updates, and improvements constantly, as in every hour or less.

The VP of IT and the CIO take to Google and find out for themselves: yep, their competitor's CIO gloated and blabbed about this at a conference the other day. It turns out that not only are they releasing code much faster, but they've also cut down on bugs, automated most manual processes, and improved customer satisfaction, which is driving up sales.

Until then, the IT chiefs had been satisfied that the adoption of new techniques and tools would make the app creation process more agile. But now they're being told that, compared with their rival, the pace and frequency with which their IT organization delivers software is, frankly, glacial.

[ Learn how value stream mapping can benefit your organization in this Oct. 8 Webinar. Plus: Learn more with this GigaOm Research Byte on VSM. ]

New paradigm to the rescue. Wait...what new paradigm?

As the scrambling begins and the names of recommended medicines for their ailment come up, DevOps and continuous delivery (CD) rise to the top of the list. But it's confusing. Are they the same thing? How are they related? And more importantly, how can they speed up software development and delivery?

Here are some important things to know about how DevOps and CD differ, intersect, overlap, and complement each other.

[ Learn how release orchestration can govern compliance, control, and integration for successful DevOps transformations in this Webinar. ]

The short answer...

...which some may not like, is that DevOps is more of a philosophy, while CD is closer to a methodology. Also, a generally agreed-upon definition of DevOps has proven elusive, an issue that in and of itself is controversial. There's no such problem with CD.

"Certainly DevOps is like the old joke about getting five people in a room and getting seven definitions—it means just about anything to anybody," says Gartner analyst Nathan Wilson.

But CD is a very specific thing. In fact, there's a book that provides a comprehensive overview: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, by Jez Humble and David Farley.

Stephen Elliot, an IDC analyst, puts it this way: "DevOps is a cultural and technical process that enables organizations to produce more software releases, faster, with better results," he says. "Continuous delivery is the name of what DevOps enables."

So, can you have one without the other?

"Yes, CD will work without DevOps, but I don't think that you can be world-class at CD without DevOps," says Farley, founder and director of Continuous Delivery Ltd.

While definitions vary, it's generally accepted that DevOps seeks to transform traditional, highly segmented IT organizations by unifying the historical fiefdoms of development and operations, so that they function as a single group.

DevOps calls for dev and ops to constantly communicate and collaborate, with mutual respect and trust, as they pursue the shared goal of creating and delivering higher-quality apps and web services much more frequently to customers.

In addition to the organizational and "soft skills" attitude changes that this goal requires, IT organizations must also set up specific processes and practices, enabled by automation tools. This is where CD comes in.

When asked to define CD, Humble told InfoQ in 2011 that CD yields software that is always ready for production and can be easily deployed to customers on demand. Of particular importance, he said, are sharp configuration management, continuous integration, and comprehensive automated testing at all levels.

"The key pattern is the deployment pipeline, which is effectively the extension of continuous integration out to production, whereby every check-in produces a release candidate which is assessed for its fitness to be released to production through a series of automated and then manual tests," Humble told InfoQ.

For example, a DevOps principle is to design applications to be easy to operate and efficient to deliver, says Martin Croker, managing director at Accenture Technology Architecture. "Small, granular components with well-defined APIs lend themselves far more readily to CD," Croker says.

Damon Edwards, founder and managing partner of DTO Solutions, is emphatic about the relationship between DevOps and CD. In his view, "there's no way" to achieve CD without having adopted DevOps practices and techniques. CD requires things like fast feedback, frictionless hand offs between dev and ops, and broad automated testing and deployment, he points out.

"If you're doing CD, you're doing DevOps," Edwards says.

The collaborative, one-team culture

A collaborative, single-team DevOps culture makes CD much more viable and effective than when a wall remains between the two camps. Some would go even further to say that both DevOps and CD are impossible to achieve in a traditionally siloed IT organization.

A company that wants to optimize the whole process, from idea to deployment, can't afford hand offs between dev and ops separated by a wall and working in silos, Farley says: "It slows us down too much and compromises the quality of our work."

When an IT organization gets to a point where it's deploying software multiple times per day, with A-B testing and phased releases, the old borders inevitably become porous. "The boundary between development and live is inevitably blurred," Croker says.

Edwards cautions against faux CD implementations, which he believes are becoming common. "Everybody now talks about it like it's the thing to do but very few companies are actually doing it."

A misguided IT organization typically starts out wanting to revamp its software release management functions via automated deployments, but it fall short because it fails to do the hard work of DevOps organizational transformation.

"CD isn't just continuous integration with automated deployment," says Edwards. He notes that these companies may take some ceremonial CD steps, but they're not fundamentally changing how they work, staying instead at a superficial level by only changing high-level processes and structures. "People like to redefine things to protect the status quo," he says. "They'll move chairs around, but when it comes to changing who has what responsibility and how they do it, they tend to bend those new ways to the old style, which is why they get the same poor results time after time."

DevOps automation is key for enabling CD

DevOps will create awareness that automation is key, and a by-product of this awareness will be a bigger commitment to the tools needed for CD. Automation is critical for achieving CD and should be present at every stage of the software lifecycle, including various checks and tests along the delivery pipeline. These tools provide instant feedback to developers and operations staff, speeding up necessary changes and revisions.

"IT moves from batch to real-time releases where small changes are made, assured, and deployed individually, potentially even to production," Accenture's Croker says.

Thus, CD demands a commitment to automate as much as possible, which significantly reduces errors that fly under the radar when teams rely on manual testing and processes.

Whole-team awareness

DevOps makes developers and operations staff more aware of the demands of each other's work, so they incorporate that perspective into what they do and how they do it. For example, when developers have a sense of perpetual ownership of their code throughout its lifecycle, and they strive to write it in a way that isn't disruptive to operations, this has a positive effect on CD processes.

"When developers understand that they're responsible if they go too fast and break things, they can figure out what the highest responsible speed is," Gartner's Wilson says. "You don't have two people arguing over what that speed is when one of them is responsible for cleaning up the mess the other one makes."

The opposite is true as well: IT ops staff gain greater awareness of the way developers work and the pressures they're under, and they make adjustments on their end to avoid production-side bottlenecks that slow down software deployments.

Embracing more functions in the organization

DevOps can loop in other teams beyond dev and ops who are often left out of the software development and delivery conversation. Historically, teams such as security, auditing, and compliance have always been brought in after the fact or seen as a checkbox during the software development and delivery process, IDC's Elliot says.

"If you're going to reinvent your deployment model, then you ought to take a look at security, audit, and compliance," he notes.

There's the potential here to embed some of those capabilities early on in the code development cycle, or at the very least to be aware of problems that may crop up later that could slow down software deployments, according to Elliot.

With CD enabled through steady, consistent DevOps practices, the VP of IT and the CIO are looking forward to more fine mornings. And with improved collaboration across dev, ops, testing, security, and other functions, teams are designing and delivering business applications much more frequently, and with less friction.

[ Learn what separates successful DevOps initiatives from unsuccessful ones in this new EMA research webinar. ]