Allianz Insurance cuts software release times with Jenkins continuous delivery tools

Computerworld UK speaks to Adam Rates, head of strategy and architecture at Allianz Insurance


Insurance may not traditionally be perceived as the most dynamic industry, but these days large insurers are increasingly required to move quickly to create new digital products. Consequently, this puts pressure on software development teams to deliver new services at speed.

Part of Allianz Insurance’s plan to reduce the time taken to deploy code for its Java-based line of business and web-facing applications has been the deployment of CloudBees Jenkins. The open source automation tool has enabled the UK insurer to adopt continuous delivery and continuous delivery practices.

Image: Allianz Insurance
Image: Allianz Insurance

Adam Rates, head of strategy and architecture at Allianz Insurance, says that the Jenkins software has helped push code into production “quicker, cleaner and more efficiently”.

“We are doing between three and four times as many code releases across [application] environments as we were before,” Rates says. 

“We can do a code release across into an environment, run a set of automated tests in half a day comfortably, depending on the complexity of the code, or in some cases in an hour if it is simple.

“That would have taken us a week to do before, maybe even a bit longer, across the environments.” 

Allianz offers a range of insurance products, such as home, motor and commercial policies. The company employees 400 developers – half in the UK and half overseas.

Allianz Insurance had previously been using tools such as Subversion for software versioning and revision control and Serena for migrations, which automates the release process across application environments. “But what we needed was a way of providing a level of control over the top of that and also providing a way of triggering things like automated testing,” says Rates.

“So we wanted to move to a much more formalised continuous integration and continuous delivery environment rather than using a set of ad hoc tools because, although we get advantages from the ad hoc tools, we don’t get any of the control and we don't get standardisation of process. And standardisation of process is really important.” 

Rates said that there are two ways Jenkins has benefited the business. Automation means that software releases are carried out quicker, but there are also improvements to code quality, resulting in a more efficient process.

“Because you are testing as you go as a result of the continuous integration environment, you are hitting any defects much earlier in the process and that is way cheaper to fix,” he says.

“It's way cheaper for a developer to fix their individual piece of code than it is once it gets into user acceptance testing and then realise you have got to go back and redo it. So you get two advantages - you get speed and you get cost."

He adds that “the consequence of that is that the business gets throughput”. 

“We can make web modifications much more quickly, you can launch new products more quickly, you can launch propositions more quickly.”

The use of Jenkins is part of a wider move to a devops methodology within Allianz. “We are continuing to look at agile and devops. You don't have to do agile and devops to get benefits out of continuous deployment and continuous integration [but] you get more benefit if you do."

However, Jenkins is just one element of the approach. “So step one is to put Jenkins over the top and automate some of the processes, step two is to get a more integrated, better continuous integration/continuous delivery environment, and step three is looking at agile and how we can improve the way we work in a devops fashion.” 

Read next: Eight useful tools for devops success

Rates says that Allianz is not currently using Jenkins to automatically push code into production.

“With something like Jenkins or a continuous integration environment you could press a button at the beginning, automatically deploy the code through environments and automatically, assuming it is part of a set of criteria, take it into production. We don't do that. We take it to the end point of user acceptance testing or preproduction environments and then the end process requires an extra set of authorisations.” 

In future Jenkins could be used for production code, but only for certain purposes.

“I think it very much depends on the environment in which we are operating and what it is we are migrating through. From my point of view, from a line of business system, no, but for a web environment where we were loading brochureware pages or changes in look and feel, yes absolutely.” 

"Recommended For You"

The relationship between DevOps and continuous delivery Allianz Insurance moves to SOA