Web Operations Engineer at the UK Government Digital Service (GDS), Laura Martin, recently gave an update on the Service’s continuous integration (CI) environment.
The Web Operations team at GDS updates and maintains the GOV.UK infrastructure, while also providing infrastructure for new requirements. Earlier this year, the team embarked on a mission to “Upgrade the Things”, with the CI environment being the first step.
“The first thing we updated was our Continuous Integration (CI) environment. We provide CI so our developers can continuously improve GOV.UK. Releasing regularly is a key part of what we do. If CI goes down, our development will halt,” Martin said in a government blog post.
Integrating the CI environment with the rest of the stack
The GDS CI environment was being hosted separately to the rest of the infrastructure, with a separate Puppet codebase. Two separate sets of codebase meant the Web Operations team had to repeat a lot of work whenever applying critical upgrades.
“We took the decision to move the CI environment to the same stack as our Integration environment. We could then deploy and monitor CI in the same way as our current infrastructure, and manage it using our main Puppet codebase,” Martin said.
Working in Jenkins
This integration move also improved the GDS’ use of Jenkins, which is now more easily configured. The Web Operations team’s main Puppet codebase automates Jenkins’ jobs and configuration. No longer do developers working in the CI environment have to do this manually through the user interface.
“Configuration change can be applied to all Jenkins instances across the estate, and this has improved the reliability of our testing,” Martin said.
It is also more effortless for developers to manage configuration by taking advantage of the Jenkins Pipeline.
Instead of developers having to go to the Jenkins UI, create a job and then add all the configuration steps, they can now just create the ‘Jenkinsfile’ (containing all the steps of the jobs they want to run) in their own repository.
Then when developers are pushing code changes to their repository, a Webhook can be used to trigger Jenkins to do its job. Jenkins will proceed with the job according to the configuration in the Jenkinsfile.
Moving forward
The GDS’ Jenkinsfile is portable, meaning if the team decides to rebuild the CI environment elsewhere in the future, developers will just need to update their Webhooks and the same Jenkinsfile can easily be applied.
The other benefit of the Jenkinsfile is it’s in version control. With changes to jobs being made with a clear commit history, the team can also see exactly why a developer chose to create the job the way they did.
“We only have one more job to do and that’s to share our knowledge with developers to help them write and test Jenkinsfiles for our 85 applications. As a team, we’ve found this work to be a rewarding experience due to the number of benefits it brings.” Martin said. “We now move on to a number of other things to upgrade, and 2017 looks to be a very interesting year for GOV.UK and Infrastructure.”
Edited from source by Cecilia Rehn.
