Industry Watch: Continuous delivery
August 1, 2010 —
(Page 1 of 2)
Related Search Term(s): agile
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.