robertdeniszczyc2
commented
10 months ago Considerations:
- wary of manual tasks going to the left as this can slow down delivery
- should also consider moving other activities to the left, for example secure by design
- moving qc to the left should not be considered to remove the need for observability in production - use shift right activities to catch problems quickly there too
- shifting assurance left lets you identify things before they become an issue, but you will also need assurance for example vulnerability scanning for dependencies should be considered left and right, to allow for vulns that arise in production after deployment
edhamiltonHO
Our engineering patterns are example solutions for addressing problems, meeting standards and living our engineering principles. They should make it easier for engineers to do their jobs. We don't have a standard way of writing patterns as we like to be a bit more flexible with their structure. Please provide us with some information on what you are proposing below
What is the pattern you are suggesting? Catch problems early (shift quality left)
What would be the benefit to the Home Office of following this pattern Why this is important It's important to catch problems early for the following reasons:
Any problems can be addressed more quickly. Tighter feedback loop. Allows problems with changes to be fixed while it is still fresh in the developer's head. Reduces development and test effort to deliver a change, as issues can be caught before a formal test phase. Problems can be caught before they can impact on your users, which will increase your users' confidence in your service.
Reduces the risk of adverse changes entering the product. Overall; this allows for faster iteration, whilst maintaining the quality of your service.
How do people implement this pattern You should:
Enable developers to test their changes in a local development environment Developers should be able to spin up a copy of the environment on their local machine Define staging environments, the testing to be done in those environments, and the progression criteria Have staging environments that match the production environment as closely as possible Test changes in a CI pipeline before they reach a staging environment (for example, run unit & functional tests) Test changes in staging environments before they reach production (for example, run system-wide and integration tests)
Additional information Add any other information you think would be useful here