How Orbitz Cut Their Release Times in Half...Twice
How Orbitz Cut Their Release Times in Half...Twice
By increasing automation and improving predictability, Orbitz cut their regular release schedule from two weeks to only four days. Here's how they pulled it off.
Join the DZone community and get the full member experience.Join For Free
Easily enforce open source policies in real time and reduce MTTRs from six weeks to six seconds with the Sonatype Nexus Platform. See for yourself - Free Vulnerability Scanner.
We’ve seen a lot of great stories recently about major organizations’ adopting continuous delivery. To the list of Etsy, Adobe, Facebook, Telsa, Flicker and others—you can add Orbitz.
Diginomica reports that two years ago, it took software developers at online travel company Orbitz around 18 days to turn a request made by the business for new functionality into a piece of software ready for deployment.
By most organizations’ standards, that’s pretty fast—and fortnightly software releases, meanwhile, did a pretty good job of keeping some 200 Java applications ticking along nicely. Many of these power the web and mobile operations of a range of Orbitz brands, including Orbitz.com, CheapTickets, ebookers, HotelClub and Orbitz for Business. Others connect Orbitz to key partners, including airlines and travel agencies.
But senior principal engineer Jacob Tomaw had a hunch that the company’s software delivery cycle could be faster still, if a number of inefficiencies could be eliminated. The key to this, he believed, would be adopting continuous delivery: a software methodology that focuses on building, testing and releasing software faster and more frequently by relying heavily on automation to continuously releasing features and functions in small chunks:
I saw that we were the kind of organization that would do very well in the transition to continuous delivery. We were already delivering apps at a very consistent cadence of every two weeks. And our builds were largely standardized. So it was all pretty predictable, but there was a lot of work going on behind the scenes, a lot of manual tasks.
What was also predictable was instability in our pre-production environment. It was pretty predictable that we’d have to patch software and pretty predictable that every deployment would be a big ordeal. And at the end of that ordeal, there would often be one or more teams that needed to patch the production environment in some way.
If you follow the principles of continuous delivery, you only release production-worthy code, so you can increase quality, but you can also increase the number of releases you do. I wanted to make that happen.
Orbitz was already using the open-source continuous integration tool Jenkins for software development. By using additional tools, Orbitz was able to support continuous delivery as well. This would orchestrate many of the steps in the software delivery cycle that had previously been manual or only semi-automated:
This move enabled us to standardize on a single infrastructure, not just for continuous integration, but also for releasing our applications. We no longer wanted to hear, “But it works on my machine” when a test failed. We needed high availability, more automated testing, consistency in our builds, and an easy way to organise our jobs.
The results of Orbitz’s work with Enterprise Jenkins are impressive. The development team went from a pipeline that was 18 days long to one of around 4 days in most cases. Tomaw comments:
By making our process more efficient, and adopting continuous delivery practices with the Jenkins Platform, we have cut our release times in half, and then cut them in half again. Additionally, thanks to automation, we now ensure that each one of the artifacts we build for production applications is produced consistently and in a repeatable way – a capability that is essential for continuous delivery.
With faster cycle times under its belt, Orbitz has also been able to institute a new policy around patching, which requires each patch to be evaluated for its contribution to margin before it’s approved. In order for a patch to get the nod, it has to contribute projected revenue at least equal to the labor expense of deploying it. The threshold is around $4,000, Tomaw explains. Otherwise, it must wait for the next release—but these days, that’s usually only 4 days away in any case.
The upshot of all this is that, back in 2013, Orbitz delivered software every two weeks. Now it’s delivered daily, sometimes twice a day. Adds Tomaw:
Over the first six months of 2015, we achieved our ultimate goal, where our release throughput exceeded the demand of product owners within the business.
If you're interested in continuous delivery and want to learn more about how you could acheive Orbitz' stellar success, you may be interested in this free whitepaper specifically focused on a crucial and often overlooked part of the continuous delivery process: the database. Download "Continuous Delivery for the Database" here.
Published at DZone with permission of Yaniv Yehuda , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.