Software development¶
How we write, test and ship code so that any Defra team, or any partner, can pick it up and run with it.
Doctrine: 1. Platforms before projects. Built as products, 2. Standards and guardrails before exceptions, 3. Reuse before buy
Principles: 1. Delivery-focused architecture, 3. Maximise value, minimise waste
Who these guardrails apply to
The core department. Whether the software development guardrails also apply to Defra's arm's length bodies is still to be confirmed.
Looking for detailed coding guidance?
These guardrails set the boundaries. The Defra software development standards are the detailed, practical guide to languages, coding style, testing, source control, versioning and release - follow them for day-to-day engineering.
GR-DEV-01 Use the supported languages and frameworks¶
Should Use Defra's approved technologies and languages for new services so that skills, libraries and support are shared.
The list, and the reasons for each choice, are in approved technologies and languages in the Defra Digital Service Manual and in the Defra software development standards. In short: Node.js with hapi for front-end and back-end services, GOV.UK Frontend Nunjucks templates, .NET or Python only where Node.js is not suitable, and no other front-end frameworks. Review approved technologies, and request new ones, on the Defra Tools Radar, which needs a Defra network and sign-in.
Why: A small, well-supported set of technologies makes it easier to move people between teams, share components and support services for the long term.
How to meet it: If you need something else, request it through the Tools Radar and record the reason in an ADR, including how the service will be supported after the team moves on. The Delivery Architecture team handles exceptions to the software development standards.
GR-DEV-02 All code in Defra source control¶
Must All source code, including infrastructure and pipeline code written by suppliers, lives in a Defra-owned GitHub organisation from day one.
Why: Defra owns what it pays for and must be able to change supplier without losing code or history.
GR-DEV-03 Protect the main branch¶
Should Main branches are protected: changes arrive through pull requests with at least one review and passing automated checks.
GR-DEV-04 Continuous integration and delivery¶
Should Every change is built, tested, scanned and deployed by an automated pipeline. Releases to production are small, frequent and reversible.
GR-DEV-05 Automated testing at the right levels¶
Should Use a balanced set of automated tests - unit, integration/contract, end-to-end journey, accessibility, performance and security - run in the pipeline.
GR-DEV-06 Manage dependencies actively¶
Should Use automated dependency updates and software composition analysis, and keep runtimes on supported versions.
Why: Unpatched dependencies are one of the most common ways services are compromised.
GR-DEV-07 Follow shared coding standards¶
Should Use automated linting and formatting, and follow the Defra software development standards, so code looks and behaves consistently across teams.
GR-DEV-08 Document as you go¶
Should Each repository has a README explaining what it does, how to run it locally, how to test it and how to deploy it, and links to its ADRs.
GR-DEV-09 Record significant decisions as ADRs¶
Should Record significant architecture decisions as architecture decision records (ADRs), kept with the code or linked from the repository's README.
Why: the reasons behind a design are lost when people move on. ADRs let the next team, an assessor or a partner taking over the service understand what was decided and why, and change it safely.
How to meet it: keep ADRs in a docs/adr folder in the service repository, using the ADR template. Write one when you make a decision that is hard to reverse, departs from a guardrail, or that someone will later ask "why did we do this?".