There's an important difference in how we use Git at GDS compared to lots of other organisations. We're very thorough when using version control because we don't want to waste the effort we've put into writing code.
If our code is still around in the future, we want people to understand what it's there for. This all comes down to making sure we are efficient with resources and paving the way for more code sharing within government.
I talked about this recently at GitHub’s Satellite 2016 event in Amsterdam, the European part of GitHub's Universe conference.
Our use of version control
During the presentation, I mentioned how version control is really useful to store context about why code is changing. A good version control system should be able to explain 2 things:
- what code is changing (you can see this by looking at the diff of the commit)
- why the code is changing (you probably can't see this by only looking at the diff)
It's often the smallest changes that are the hardest to understand years after they're made. For example, one of our web operations engineers Dan made a configuration change to our SSL ciphers in 2014. This was the diff:
-ssl_ciphers HIGH:!ADH:!kEDH;
+ssl_ciphers HIGH:!ADH:!kEDH:!aNULL;
From looking at the above, it's really hard to figure out what this change was trying to achieve. Why is it important? What was Dan thinking when he was working on it? So there's a question about where to store the 'why'.
At GDS we store the why in our Git commit history (a log of all the commits we have made). This differs from some organisations that choose to to use GitHub pull requests to explain why they are making changes (for them the commit history doesn't matter). We think there are plenty of good reasons to work in the way we do.
Individual commits are available using your local copy of the repository. If our Wi-Fi is broken, or GitHub is down, or the internet is just having a bad day, the context about our code is still easy to access.
But more fundamentally we're conscious that we're working on the government's website - we're planning to be around for a very long time. There's no reason for us to store context about our code with our code hosting service (GitHub), which may one day change, when our open source version control software (Git) gives us a perfect way for us to do that.
Our GitHub projects
At the same time as being thoughtful about what parts of our software development takes place in commits instead of pull requests, we've built a number of GitHub projects all aimed at supporting our development. These include:
- Fourth Wall, which is a project that shows a teams’ open pull requests on a monitor
- the deploy lag radiator, which uses branches that we push to GitHub during our deployment process to show how far behind production is
- the seal, which is a Slack bot that posts in team chat rooms so that they know which pull requests have been reviewed recently and which haven't been looked at for a while
Being as open as possible
Also at GitHub Satellite, I talked about how we try to be as open as we can. Our 10th design principle is "make things open: it makes things better" and the GOV.UK roadmap being a public Trello board is a great example of this.
When it comes to code, we publish everything we can on GitHub. Our secrets (passwords and keys) are nicely separated from our source code, and we host our own copy of GitHub Enterprise to keep those safe.
I reiterated a point our head of technical architecture, James Stewart made 3 and a half years ago: we publish all of our code, but not as supported open source software. We do publish some of our work as supported open source, but those are small reusable bits that we're confident will be useful for other people.
Jenny Duckett presented alongside me at GitHub Satellite, discussing the process of transitioning previous individual government websites to GOV.UK. Both our talks contained similar messaging in that all the work we do closely follows our GDS design principles.
Let us know if you have any thoughts on how we are using GitHub at GDS. You can leave comments in the section below.
You can follow Alex 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.
