Be fast or stay behind - Building a Continuous Delivery Platform

Ten years of continuous growth leave many stretch marks on any website, like increasing maintenance overhead, lengthy and complex internal processes and lots of code and configuration that nobody knows about. A Windows-Linux migration in the past also does not help to achieve a clean platform.

On the other hand, being a market leader does not leave any room for relaxation but requires us to stay ahead. We need to be faster than the competition and make sure that our own size and being part of a larger corporation does not slow us down.

Continuous Delivery is not just a buzz word but the answer to many of our current problems. Today we envision our data center and the various IT departments as building blocks in a Continuous Delivery Platform (CDP) that strives to shorten the time it takes to convert an idea into productive code.

This talk starts from a big picture of a typical web company and drills down into the technical and organizational challenges that stood in the way of creating a CDP. Our developers turning agile and doing everything through SCRUM was only the start of a series of profound changes that touched all IT departments and beyond.

DevOps helped us a lot to explain to our management and colleagues what is going on and what we want. But only a brand-new deployment and configuration management brought the actual break-through to shared responsibility and teams developing operational thinking.

An important learning was that engineers come together through solving common problems as a team. In our case we had to deal with two main concerns: Linux and Java.

Linux being the choice operating environment we started to do things the Linux Way and package all our software, configuration files and even content into RPM packages, thus greatly simplifying the problem of deployment and system management. Since our developers build the RPM packages they also get much more involved in site operations and suddenly the whole DevOps idea actually works out for us.

Java being the choice coding language (with a huge code base :-() and a lot of “Java thinking” lead us to write a bridge between Java and Linux: Our Nexus YUM plugin translates between a Java world that knows only Maven and a Linux world that likes to install packages via YUM. The automated build process in TeamCity creates RPM packages and puts them into the Nexus which serves the same RPM packages as a YUM repository to our servers. This simplifies the handover from development to operations and is a big performance boost for our delivery chain.

These and other technical solutions come together with many organizational changes – e.g. giving developers more access in the data center – to create the foundation for our Continuous Delivery Platform and enable everyone to focus on working the software while relying on a reliable delivery tool chain below.

Another important learning is the way how to ensure the management buy-in into what essentially started out as an internal grassroots movements. Previously closely guarded kingdoms are now open to common responsibility based on a trust relationship between development and operations.

With even product owners seeing the business value of web operations, ImmobilienScout24 is now in a much better position to deliver business value as fast as possible to our web platform.

We would like to share with you the details of our journey, the ideas that helped us along the way and the code that we wrote. This talk will be useful to both managers and engineers who want to embark on a similar path.