As part of the GDS commitment to code in the open, we have opened up GOV.UK’s application deployment code. This came with a number of challenges but it increased the development team’s efficiency and collaboration. Find out why we opened …
There are two big concerns government organisations have around making source code open. They want to know which subsets of the code should be kept closed and how to code in the open securely. To address these questions I’ve introduced two pieces of …
As technical writers at GDS we create technical documentation which includes instructions and supporting content for the products we build. We want to make our documentation consistent across all products, but also make it easier to work closely with our …
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 …
On the GOV.UK team, all our changes are peer reviewed using Github's pull request system. If a developer wants to make a change to one of our projects, they need another developer’s approval before the change is accepted into the …
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 …
Point 8 of the Digital by Default Service Standard that we publish on GOV.UK says that source code for government services should be open and reusable, and our 10th design principle is "Make things open: it makes things better". We …
Other teams around government frequently ask us about our use of GitHub, and rather than bury those answers in email it seemed time to follow Mike Bracken’s directive and publish (not send) our answers. I’ve made some assumptions here about …
GOV.UK