Keeping software delivery on track
August 30, 2012 —
(Page 1 of 2)
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?
What continuous integration isn’t
A recent report by analysis firm Voke on agile that found only 49% of enterprises were using continuous integration. What’s worse, far too many teams are doing it wrong:
• It’s not just running a tool. “When people say they do continuous integration, what they actually do is they’re running a continuous integration tool, and that’s not the same as doing continuous integration. Crucially, continuous integration is a practice, not a tool,” said Humble. And what is that practice? “The essence of it is, you’re always pushing into mainline, into trunk, and working off trunk.”
• It’s not nightly builds. Development teams shouldn’t deceive themselves, Humble said: “A nightly build is not continuous integration. If you are not checking into trunk at least once a day, if you don’t have a suite of tests that runs in a few minutes, if you don’t pay attention when the build goes red and make it the highest priority of the team to fix it now, you’re not doing continuous integration.”
• It’s not hours of tests. Even the most extreme continuous deployment (see Timothy Fitz’s report, “Doing the Impossible 50 Times a Day”) depends on a test suite that takes just nine minutes (albeit distributed across 40 machines). At the other end of the spectrum, too many companies have no comprehensive automated testing in place.
• It’s not sifting through failure reports. “Friends don’t let friends grep log files,” said Anders Wallgren, CTO of Electric Cloud. “If you’re running a two-hour test suite and having to carefully watch the output, you don’t have to. We’re watching those builds in real time and can pinpoint what the problem is for you.”
• It’s not just running build and unit tests on a feature branch. According to Humble, continuous integration only applies to regular merges into the centralized code repository, or trunk, a subject of some controversy among developers fervently embracing distributed version control systems such as Git.
As support for his argument that continuous integration needs not require a special tool, Humble points to a 2006 article by James Shore, “Continuous Integration on a Dollar a Day,” which suggests all you need is an old workstation (to run the builds), a rubber chicken (to take to your desk to alert everyone that you have checked in changes and a build is running), and a desk bell (which you ring if everything passes).
Related Search Term(s): agile, software delivery
Share this link: http://sdt.bz/36887
Most Read
Latest News
Resources
SAP unveils SAP HANA platform innovations for Big Data and spatial processing
Features include smart data access and expanded cloud deployment options
|
|
|
Alteryx raises $12 million to put Big Data analytics in the hands of all business analysts
Quest founder's firm, Toba Capital, selects Alteryx as its first analytics investment
|
|
|
Google I/O kicks off
Developers get new APIs and tools, and the Go language hits version 1.1
|
|
|
Jelastic launches new version of its Java and PHP hosting platform
Jelastic today announced the launch of a new version of its ultra-scalable cloud hosting platform
|
Telerik adds back-end services to Icenium mobile tool suite
Icenium Everlive makes the suite a complete app development platform, the company says
|
|
|
CollabNet fuses CloudForge, TeamForge
New pricing structure and integration gives developers an enterprise-grade choice for dist...
|
|
|
Eclipse release train for Kepler arrives June 26
New version of Eclipse includes Stardust for business process management, and Orion 3.0 fo...
|
|
|
Google I/O kicks off
Developers get new APIs and tools, and the Go language hits version 1.1
|
IDC MarketScape: Worldwide Cloud Testing and ASQ SaaS
Demand for solutions to test applications on the cloud and for the cloud is rising signifi...
|
|
|
Get to Know the Database Decision Factors
What should you look for when choosing a relational database system? This informative arti...
|
|
|
Exploring the Database Forest
Today’s database technology landscape is more dynamic and varied than ever before. What’s...
|
|
|
Data Management Resource Guide
Today’s data is generated by more than just applications. Data is generated by trillions o...
|