Continuous delivery at the Ministry of Justice

One of the things we’ve been working on with the Ministry of Justice is creating a consistent way for teams to build and deploy their applications.

This means that they can build new applications more quickly; it also means that developers working across different products can follow a tried and tested workflow process.

For context I’m going to talk about two tools in particular: Git and Docker.

Introducing Git

Git is a version control system designed to make it easy to work on code in a team. The Ministry of Justice do their best to share as much code as possible, so most of what they write is published on GitHub.

One of the key features that GitHub gives, on top of just hosting the git repositories, is pull requests. Pull requests provide a great way to review code but also an excellent hook for integrations to run tests or builds of the new code.

Introducing Docker

Docker enables developers to package applications into ‘containers’ which can be tested and released in a consistent manner. Containers have been around in Unix based operating systems for a while. Recently, they’ve become a popular tool, partly due to Docker making containers easier to use on Linux. In addition they provide a nice abstraction layer on top of operating systems, making it easier to build once and deploy on any OS or virtual machine.

One thing that sets containers apart from other tools (or just plain virtual machines) is that they are based in layers which makes small changes quick to download and quick to start up.

Combining Docker with Github pull requests

This got us thinking, why not build a new Docker container each time a GitHub pull request is opened and then publish it to a test environment? This makes it possible to ‘see’ what’s being built before it is released.

To do this, we used Jenkins to build a new container using the GitHub pull request builder plugin to trigger the build.

We then publish the container to a demo environment and use Salt to configure a virtual host on nginx. This gives us a URL (like my-branch.domain.net) that anyone in the team can follow to see the new version in action. We also automatically post the URL in a team chat so that everyone in the team has visibility on changes to the application.

The same URL can also be used to test a feature with users before it’s released more widely.

One of the best things about this process is how it supports collaboration between designers, content editors, researchers and developers. Any feedback can be posted in the pull request before it is merged and released.

So far, two product teams at the Ministry of Justice are using this workflow, and they’re looking to introduce it more widely.

I’ll hopefully follow up with some technical details on how you could set this up yourself! Meanwhile, you can find some of the necessary salt states on GitHub https://github.com/ministryofjustice/moj-docker-deploy-formula

This post is adapted from the original on the MOJ Digital Blog