Migrating from tightly coupled release processes to CI/CD
Submitted By Jenkins User Jon Brohauge
Leading Danish insurer chooses Jenkins as the “de facto” product to build their CI/CD.
Organization: Topdanmark Forsikring A/S | https://www.topdanmark.dk
Industry: Software Development
Team members: Jon Brohauge, DevTools Engineer | Nikolaj Ougaard, DevTools Engineer, both with Topdanmark A/S
Programming Language: Java
Platform: Docker or Kubernetes, Linux, Windows
Version Control System: GitHub
Build Tool: Maven
Community Support: Jenkins Users Google Group or IRC Chat, Networking at Jenkins event, Spoke with colleagues and peers
Insurance engineers automate their build process
with a highly-configurable Jenkins platform.
Background: The engineers at this leading Danish insurer, Topdanmark Forsikring A/S, wanted to create a platform to migrate away from handheld deployments. These deployments were taking as long as three months from start to finish, so they looked to Jenkins to get the job done more efficiently.
Goals: We had two main goals:
To achieve a complete autonomous build process, from the cradle to grave, i.e., from git-commit to deployable docker image stored in our private Docker repository.
To empower any developer to order a Jenkins runtime and have it in a working state within minutes.
Solution & Results:
By combining the power of Jenkins, Docker, AWS, Java, and a sprinkle of Groovy, the team managed to create a fully automated process. Now any developer can order a Jenkins instance and have it populated with repositories from relevant organizations situated on our Github Enterprise Server. Utilizing Jenkinsfiles, it is now possible to build, test, archive and deploy artifacts by simply committing a change to a repository.
We also wanted to do the same via our handheld release process, which previously took anywhere from 1-3 months. And that’s not including ordering a build environment and a semi-automatic hand-built Jenkins 1.x.
We now use JCasC whenever possible. It helps us keep configuration the same across multiple instances. Using Pipeline plugins combined with the Amazon-ECS plugin, it allows us to utilize the ability to have a large number of build-agents ready to deploy any Jenkins job based on Jenkinsfiles.
We used Jenkins because almost everyone knows what Jenkins is and how to use it. It is the “de facto” product to use in our world. And it’s extremely configurable. In doing so, we’ve realized great results, including:
- 100% automatic creation of Jenkins instances
- the ability to release and deploy an artifact whenever, wherever
- happy software developers, developing software
- smaller monoliths