You may have heard endless great things about continuous delivery (CD), but sometimes a real tangible example speaks more than any diagrams or calculations ever could. Today, budget travel helpers Orbitz Worldwide revealed that, thanks to adoption of Jenkins powered CD, they’d squeezed software release cycles by 75%. In this interview, Jacob Tomaw takes up the story to tell us how they managed this massive switch, and what their experiences taught them.
What was it that pushed you towards Jenkins? What were the main market forces?
We use Jenkins as our continuous integration server to basically just run a load of different technical functions, and we use CloudBees to help us support that. We use Enterprise Jenkins, along with some of the plugins they have developed on top of the open source project.
Many, many years ago we used a different tool that was not as well supported and not as common for people to have experience using. There was a cost training people, it really led to a lot of apathy, and it all really died a very long and quiet death when we started to take a stronger focus on continuous integration 5 or 6 years ago. We needed to have a new continuous integration tool and this was about the same time when the Hudson project and the Jenkins project separated.
We chose Jenkins because it appears to have the largest community around it. And what’s great is that we’re allowed to contribute to a load of open source projects – submit some other patches back, report on other plugins – stuff like that – and it’s turned out that I’m Jenkins really gets what the Java community feels about solving the continuous integration problem.
In the enterprise, we really made a big effort to make sure that we are able to recover from any problem. We experimented with Jenkins as a way to make sure our delivery platform was always available, so we would be highly available if there was any kind of disaster we needed to recover from. We wanted to be able to do that in the normal way that we deliver software, and using Enterprise Jenkins allowed us to do that.
Is open source software a priority for Orbitz?
We definitely use a lot of open source – a lot of our stuff is built on top of open source packages, as well as our tools. We try to open source what we can, and in future, we hope to contribute even more open source back to the community. When we look at solving a problem, we look at both open source and paid tools generally.
What were the challenges you faced in implementing continuous delivery?
The first thing that we did when we were setting up continuous delivery was that we transformed our technology organisation into a learning organisation. And through various different practices – adopting agile, adding a lot of testing capabilities into our production platform – it helped us to learn and do quick feedback through processes like root cause analysis. Learning became a key thing to what we do in our technology organisation.
So that was the first step that allowed us to go into continuous delivery – knowing that we would have a lot of mistakes, but we would continue to learn. And we are continuing to learn how we can do continuous delivery better and better still today.
I think the big thing that we learned in 2014 when we made our first documentable increase was that we were willing to accept more risk that we were before, and that we would recover from it.
The second part required me pushing people a little bit more into accepting risk and kind of giving people lots of reassurance – yes, we know we are doing something risky, but the payoff is greater than what we’re risking.
There’s lots of little things I did that helped us achieve our goals, but the big thing I did was to be the person that says this is something that we can achieve. I have confidence that we’re the kind of organisation that can achieve this, we have the people that can do this work, and then I set rather arbitrary goals on a monthly basis for how we were going to achieve this. And to my amazement, we did it.
You’ve done some pretty impressive things in your company with automation – how do you think you can fine tune know what you’ve already done?
Fine tuning I think is what’s key – that’s what we want to do. Right now we have all of our applications. In 2013, we were delivering everything every 2 weeks – now, things can be delivered everyday. We want to get everything able to be delivered every day, but the key is we want our product managers to be more involved, and we want our development team to be more involved.
We’re adopting DevOps practices, where our teams control operation of the applications and these are products owners on our teams who are saying, “this change is good, I want it in production now.” They’re not just automatically pushing it to production because it’s done – they’re pushing it into production because it’s what our product owners want. So it’s enabling the teams and product owners to be more in control.
We have a lot more to learn still. We continue to refine the workflows that we have in Jenkins and make them more robust. Other things that are enabling us to develop on this are things like different orchestration tools. We’re looking at open source orchestration tools that can help a little bit, but a lot of it is that we have a lot of annual tasks that we do now that we can fully automate.