Builds are not agile. We’ve been told this because they traditionally have been done at the end of the day, when developers have gone home and the results await them when they come in the next day. A good portion of the morning is spent trying to find the errors, assigning them and getting them corrected. Daily builds worked when companies were on an 18-month release cycle for software, but companies need to be able to adapt quickly to new opportunities and changes in the marketplace.

So the term “continuous integration” was invented, to basically mean doing incremental builds. Every time a new bit of code is tested and written, do a build to make sure it isn’t breaking the prior build. By doing these often, and in iterations, it’s easier and faster to find the errors and have them fixed. But then the code still has to go through QA and deployment, which could add time to the release.

But now, we’re told, even that’s not agile enough. Now we’re on to something called “continuous delivery,” meant to bring developers, business and IT operations together so that every iteration—every build—gets released to the public when it’s been proven to work.

Among the champions of continuous delivery is Jez Humble, a product manager at ThoughtWorks Studios, which makes agile ALM software. Humble has co-written the upcoming book “Continuous Delivery” for Addison-Wesley. “It’s common that [developers] do not take operational needs into consideration” when they’re writing their code, he said. “Weeks of stabilizing and integration are not taken into account.”

That is because in traditional waterfall development, and even agile development using continuous integration, the steps of analysis, design, development and testing occur before the QA and deployment handoffs occur. Even if you’re working in iterative steps, Humble said, operational constraints aren’t even talked about until after the business and development sides say the software is ready to go.

In fact, Go is the name of ThoughtWorks Studios’ new agile release management software. It replaces Cruise, which was the continuous integration component of the company’s ALM suite that includes Mingle and Twist. Go is about continuous delivery, as the suite takes on the mantle of adaptive ALM. Go includes dashboards for monitoring the processes and application environment; enables testing in parallel so users can see which check-in broke which build; and provides a centralized infrastructure for continuous integration and release management—what they call continuous delivery.

Continuous delivery brings business analysts, developers and IT operations workers together in what Humble has called the “deployment pipeline.” It is defined by close collaboration between business and development, QA, and IT operations. This enables organizations to tie software releases to what the business needs, and not what IT says is doable at any given moment, he explained. By bringing IT into the discussion early, the necessary environment can be provisioned up front, and monitoring can be created to ensure that when the business says the software is a go, the IT team is ready to put it into place.

The goal, he said, is to create a reliable, repeatable process for releasing software in which almost everything can be automated. Humble said organizations need to destroy all their “works of art”—all the things that can’t be reproduced and automated. Organizations should model their processes—that delivery pipeline—and then automate them.

Every check-in goes through the process. At first the feedback is quite fast, while later on it slows down, but that is offset by the fact that confidence in the build is that much higher from having made earlier and more frequent trips down the pipeline.

Humble, who discussed continuous delivery in an SD Times-sponsored online agile conference, also believes development organizations need to “bring the pain forward. Pain is releasing, so if it hurts, do it more often. Release all the time. This will fundamentally change the way your work.”

Among the tenets of continuous delivery, according to Humble:
Build quality in.
‘Done’ means released.
Everybody is responsible for delivery.
Look for continuous improvement.

It’s part of ThoughtWorks Studios’ “holistic” approach to agile release management, by which they mean you have to be able to factor changes into the software project. Managing director Cyndi Mitchell summed it up this way: “What we know on Day 1 is not what we will know on Day 21.”

David Rubinstein is editor-in-chief of SD Times.