The GDS Way
The GDS Way documents the specific technology, tools and processes that GDS teams use to build and operate services.
It’s not intended as guidance for anyone working outside GDS - you’ll find that in the Service Manual.
About The GDS Way
The GDS Way shares agreed ways of working so service teams benefit from:
- using similar tools
- central procurement
- costs savings as new teams will be cheaper to spin up
The GDS Way makes 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:
- ways of working
- technology and tools
All 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 agile delivery principles 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.
How to add new guidance
Contribute to this repository by making a pull request in GitHub for discussion at the GDS Way Forum.
You can also read the service manual to find out about learning about and writing user needs.
Thank you for your contributions as we develop this repository.
When you create a new Markdown file follow this pattern and then make a pull request:
--- title: Thing you're writing a standard about last_reviewed_on: yyyy-mm-dd review_in: 6 months --- # <%= current_page.data.title %> 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 GDS Way Forum
This site documents some of the decisions agreed at the GDS Way Forum about the products we operate.
The GDS Forum meets once a month. The Forum is lead developers and technical architects representing GDS programmes who are responsible for communicating and implementing the GDS Way.
The Forum reviews:
- all GDS Way open and closed PRs
- expired guidance and if it should be continued
- possible subject areas and ownership of new content
Contact The GDS Way Forum
- How to name software products
- Choosing a programming language
- Style guides
- How to manage third party software dependencies
- Building accessible services
- Supporting different browsers
- How to optimise frontend performance
- Documenting architecture decisions
Version control and deployments
- How to store source code
- Using Pull Requests
- Writing READMEs
- Writing release notes
- Use continuous delivery
Hosting and infrastructure
- How to host a service
- How to manage DNS records for your service
- Use configuration management
- Operating systems for virtual machines
- Use a web application firewall (WAF)
- Use datastores
Logging, monitoring and alerting
- Store and query logs
- How to monitor your service
- How to manage alerts
- Make data-driven decisions with Service Level Objectives (SLOs)
- Run a Service Level Indicator (SLI) workshop
Operating a service
- Understand the risks to your service
- How to track technical debt
- How to manage access to your third-party service accounts
- How to do penetration testing
- Performance testing
- How to send email notifications
- How GDS provides user support
- Incident management
- How GDS uses quarterly planning
- Chief Digital and Information Office team
- Technical Operations team
- Principle of least privilege
- Tracking access control
- Secret auditing
- Git pre-commit