Our team makes sure the GOV.UK infrastructure is up to date and maintained, while also providing infrastructure for new requirements. At the moment it’s our mission to “Upgrade the Things”, which involves a series of major updates to our infrastructure.
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.
Integrating our CI environment with the rest of our stack
Our CI environment was being hosted separately to the rest of our infrastructure, and this meant it also had a separate Puppet codebase. Two separate sets of codebase meant we 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.
Improving our use of Jenkins
This move also improved our use of Jenkins, which we were previously using with both sets of codebase. We use Jenkins to automatically run tests on recent developer code changes, and then report back the status of these tests to our Github repository. Now we have integrated the CI environment with our Integration environment, our ability to configure Jenkins has improved.
Configuration of Jenkins is now as easy in the CI environment as it was in the Integration environment. Our 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.
We’ve also made it easier 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.
We encountered a few challenges and learning experiences when creating the file. This was mostly because Jenkinsfiles are written in the Groovy programming language, which our team had little experience with. Once we created the Jenkinsfile, we ensured the code could be reused by developers and other infrastructure teams within government by making the common methods openly available.
Configuring a reusable Pipeline
We wanted to make sure we could use the same Pipeline configuration for a number of different source repositories. This means that when a developer creates a new application, they just need to add a standard Jenkinsfile to their repository and this will automatically run Jenkins.
We did this in Puppet by creating a defined type for our standard Pipeline job. We then applied the create_resource function to create a Jenkins job for each of deployable applications (ensuring these existed in Puppet too). Now we can easily apply changes to all the jobs we’re running.
Next steps
The great thing about the Jenkinsfile is it’s portable. If we decide to rebuild our CI environment elsewhere in the future, it will be incredibly easy for us to just apply the same Jenkinsfile and tell developers to update their Webhooks. The other benefit of the Jenkinsfile is it’s in version control. With changes to jobs being made with a clear commit history, we 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. 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.
You can follow Laura on Twitter, sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
