Welcome to the UKHSA Development Standards repository. It contains guidelines and best practices for engineering teams who are designing, building, and maintaining software at UKHSA.
The content here is a work in progress. We are publishing it early to foster collaboration and encourage feedback.
We are currently on our second draft of the guidance. We expect at least two more before we reach v1.
These standards apply to all engineering teams involved in building and operating software at UKHSA. They cover the full software delivery lifecycle, from planning and design through to deployment, monitoring and decommissioning.
The guidance is intended to support teams in meeting the expectations of architecture, security and governance functions by embedding good practice into day-to-day delivery.
Intended audience:
- Software engineers and developers
- Engineering leads and delivery teams
- People involved in designing, building or operating software systems
The following terms are used throughout this guidance to indicate the strength of each requirement. These are adapted from RFC 2119 and contextualised for UKHSA:
- MUST: This requirement is mandatory. It applies universally and must be followed without exception unless formally approved.
- MUST NOT: This action is explicitly prohibited. It must not be taken under any circumstances unless an approved exception is in place.
- SHOULD: This is a strong recommendation. There may be valid reasons to deviate, but the implications must be understood, justified and documented.
- SHOULD NOT: This is a strong recommendation against a practice. Exceptions may exist, but they must be carefully considered, justified and documented.
- MAY: This is an optional practice or recommendation. Teams may choose to adopt it based on context, value or preference.
Each section of this site addresses a specific aspect of software development, including security, environments, quality assurance and measurement. Teams are expected to apply these standards consistently, and to document any exceptions with appropriate justification.
When changes to the docs are merged into the main branch a workflow is started which triggers a release on the
downstream standards-org repository.
This means you need to ensure that your main branch contains what you're happy to be published to the standards-org
website, so check before you merge!
We welcome contributions to improve these guidelines. Please read our Contributing Guidelines for details on how to get involved.
Unless stated otherwise, the codebase is released under the MIT License. This covers both the codebase and any sample code in the documentation.
The documentation is © Crown copyright and available under the terms of the Open Government 3.0 licence.
// TODO