The GDS Way
The GDS Way documents the specific technology, tools and processes that GDS teams use to build and operate the services GDS is responsible for, you can find out about them in the Service toolkit.
We’re sharing it openly because we hope it’s useful for people to see how we do things. But it’s not intended as guidance for anyone working outside GDS - you’ll find that in the Service Manual.
About The GDS Way
In the early years of the Government Digital Service, development teams chose how to build their services, picking the most suitable tools and approaches for their projects. Now we’re at the point where having some agreed ways of working for new teams is helpful. Some of the things we’re hoping to achieve with these agreed ways of working are:
- use of similar tools across GDS
- procurement once centrally for GDS
- costs savings because new teams will be cheaper to spin up
The phrase we use for these agreed ways of working is The GDS Way. This guidance will make it easier for projects to get started while still giving teams flexibility to do something different if their project needs it.
The GDS Way includes:
- consistent terminology
- consistent ways of working
- consistent technology and tools
- consistent measures
This site documents some of the decisions agreed by the Tech Ops Forum about products we operate. The decisions are made in alignment with Service Manual which covers service design more broadly.
Products at GDS in discovery or alpha development phases must follow instructions set out in the Service Manual and also have the option to follow the standards in this repository.
Products in beta and live phases must follow both the instructions set out in the Service Manual and the standards in this repository.
Standards are based on formal decisions made by the tech forum. The standards have an expiry date to ensure we review our decisions and assess whether they are still working for GDS as an organisation.
The following standards will help you name your service, choose an appropriate programming language and where to store your code:
- how to name software products
- choosing programming languages
- how to store source code
- how to manage third party software dependencies
- how to optimise frontend performance
- how to track technical debt
These standards will enable us to maintain a consistent operating environment across our services:
- how to host a service
- how to manage DNS records for your service
- how to monitor your service
- operating systems for virtual machines
- responding to problems
- how to send email notifications
- how to store and query logs
- how to do penetration tests
- how to manage access to your third-party service accounts
- how to publish open source code
- use configuration management
- Support Operations
Manuals are informative guides, not necessarily based on any formal decision or standard:
Adding new guidance
We’d like to thank all contributors for their suggestions as we continue to develop this repository, so we can seek the best way to build and operate our services enabling us to deliver at scale.
If you think you can contribute a change to this repository which reflects current practice at GDS, make a pull request in GitHub and we’ll discuss it at the Tech Ops Forum meeting and in the #gds-way Slack channel.
Alternatively contact us by email.
When you create a new Markdown file please ensure it follows this pattern and make a pull request:
--- title: Thing you're writing a standard about expires: yyyy-mm-dd (6 months from now) --- # <%= current_page.data.title %> <%= partial :expires %> Introduction of a couple of paragraphs to explain why the thing you're writing a standard about is important. ## User needs Why do we do this thing? Who is it helping? ## Principles What broad approaches do we follow when we do this thing? ## Tools What specific bits of software (commercial or open source) do we use to help us do this thing?
The service manual has some useful information on learning about and writing user needs.