Keeping software delivery on track
The long-distance runner rounds the track and starts down the final 200-meter straightaway, but stumbles dramatically. The back of the pack has nothing left to give. The leader lopes ahead effortlessly. Meanwhile, a surprise surge propels an athlete past four frontrunners. She slides across the line in time to win the silver medal.The Olympics are an apt metaphor for peak performance of software deployment and release. Runners spend years circling the track, becoming ever more efficient at their sport. They work their way up through regional, national and world competitions, practicing delivery under pressure. But only the best make it to the Olympics, and once there, some fail ignominiously while others show that strategy is crucial when it comes to the final heat.
Avoiding dramatic blowouts in the “last mile” of the software life cycle has gained popularity thanks to David Farley and Jez Humble’s book “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.” Several new tools focus on elements of the life cycle after development and testing. And in 2012, the focus is increasingly on deployment, as open-source continuous integration tools such as Jenkins gain popularity.
Even the distinction between deployment and delivery is being actively debated, along with the utility of canary releases and feature toggles. These are all signs that the DevOps movement—bringing operational concerns into the early parts of the requirements and development cycle—is gaining mainstream awareness.
But like the weekend warrior whose training plan falls far short of competitive standards, is the average software team even ready to dream of continuous delivery? Has its prerequisite—continuous integration and build management—been met?
Read the complete article on SD Times: http://sdt.bz/36887#ixzz265kPC1bx