Skip to content
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
154 lines (100 sloc) 6.36 KB
title: 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:
* terminology
* ways of working
* technology and tools
* measures
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 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.
## Ways of working
GDS works on the highest priorities while supporting its live services and adjusting its plans when priorities change. To do this GDS uses Agile at scale to plan and carry out its work in a quarterly planning cycle, find out:
- [how GDS uses quarterly planning](../ways-of-working/quarterly-planning.html)
## Standards
Standards are based on formal decisions made by the [GDS Way Forum](#the-gds-way-forum) and have an expiry date. Expiry dates ensure decisions are reviewed to check their continued relevance for GDS.
### How to build software
The following standards help you build your service, for example choosing consistent names or an appropriate programming language. Find out how to:
- [use continuous delivery](standards/continuous-delivery.html)
- [name software products](standards/naming-software-products.html)
- [choosing programming languages](standards/programming-languages.html)
- [store source code](standards/source-code.html)
- [manage third party software dependencies](standards/tracking-dependencies.html)
- [optimise frontend performance](standards/optimise-frontend-perf.html)
- [track technical debt](standards/technical-debt.html)
- [check if your service is ready for production](standards/production-readiness.html)
- [understand the risks to your service](standards/understanding-risks.html)
- [document architecture decisions](standards/architecture-decisions.html)
### How to operate services
These standards enable us to maintain a consistent operating environment across our services. Find out how to:
- [host a service](standards/hosting.html)
- [manage DNS records for your service](standards/dns-hosting.html)
- [monitor your service](standards/monitoring.html)
- [configure operating systems for virtual machines](standards/operating-systems.html)
- [manage alerts](standards/alerting.html)
- [run a Service Level Indicator (SLI) workshop](standards/slis.html)
- [send email notifications](standards/sending-email.html)
- [store and query logs](standards/logging.html)
- [do penetration tests](standards/how-to-do-penetration-tests.html)
- [manage access to your third-party service accounts](standards/accounts-with-third-parties.html)
- [publish open source code](standards/publish-opensource-code.html)
- [use configuration management](standards/configuration-management.html)
- [run performance tests](standards/performance-testing.html)
- [use data stores](standards/data-stores.html)
- [use a web application firewall (WAF)](standards/web-application-firewall.html)
You can also contact:
* [Cyber Security](standards/cyber-security-overview.html) making it easier for GDS to provide secure services
* [Reliability Engineering](standards/reliability-engineering.html) about their shared platform to distribute tools and services
### Incident management
Incident management at GDS focuses on restoring operations as quickly as possible. Find out how:
- [GDS provides user support](standards/user-support.html) for service teams and users
- [to manage technical incidents](standards/incident-management.html) for your service
## Manuals
Manuals are informative guides, not necessarily based on any formal decision or standard:
- [programming language style guides](manuals/programming-languages.html)
- [setting up logging](manuals/logging.html)
- [licensing](manuals/licensing.html)
- [how to review code](manuals/code-review-guidelines.html)
## 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.
### Submission template
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
# <%%= %>
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
Contact the GDS Way Forum using the [#gds-way Slack channel]( or by email at <a href=""></a>.
You can’t perform that action at this time.