Fix broken links (#321)

- Fixes #316
- Fixes #319
- Fixes #320

Author: stefaniuk

.github/workflows/markdown-check-links.yml

@@ -14,7 +14,7 @@ jobs:
       - uses: actions/checkout@v3
         with:
           fetch-depth: 0
-      - uses: gaurav-nelson/github-action-markdown-link-check@9710f0fec812ce0a3b98bef4c9d842fc1f39d976 # 1.0.13
+      - uses: gaurav-nelson/github-action-markdown-link-check@d53a906aa6b22b8979d33bc86170567e619495ec # 1.0.15
         with:
-          use-quiet-mode: 'yes'
+          use-quiet-mode: "yes"
           config-file: .github/workflows/markdown-check-links.json

CONTRIBUTING.md

@@ -6,7 +6,7 @@ In this guide you will get an overview of the contribution workflow from opening
 
 The framework is concerned with engineering best practice at NHSD, however, operational matters (e.g. structure of teams, roles and responsibilities, etc.) are out of scope. Please consider this when adding new content, and if in doubt, any of the code owners will be more than happy to discuss.
 
-If you're new to Github and/or Markdown, Github's own [contributor's guide](https://github.com/github/docs/blob/main/CONTRIBUTING.md) provides good signposting on these topics.
+If you're new to Github and/or Markdown, Github's own [contributor's guide](https://github.com/github/docs/blob/main/.github/CONTRIBUTING.md) provides good signposting on these topics.
 
 ## Using issues
 

README.md

@@ -34,7 +34,7 @@ The philosophy underpinning this framework advocates:
 The framework is a companion to:
 
 * The [NHS service standard](https://service-manual.nhs.uk/service-standard), with cross-references in this format: [SERVICE-RELIABILITY](https://service-manual.nhs.uk/service-standard/14-operate-a-reliable-service)
-* The [NHS Digital architectural principles](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles), with cross-references in this format: [ARCHITECTURE-SECURITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/adopt-appropriate-cyber-security-standards)
+* The [NHS Digital architectural principles](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles), with cross-references in this format: [ARCHITECTURE-SECURITY](https://digital.nhs.uk/developer/architecture/principles/adopt-appropriate-cyber-security-standards)
 
 ## Contents
 

continuous-improvement.md

@@ -99,7 +99,7 @@ The benefits of improving these areas are:
 
 ## Identifying improvement opportunities
 
-Regular team retrospectives are an effective way to identify improvement opportunities and actions. Another potential source are periodic reviews using tools such as the the [AWS](https://aws.amazon.com/architecture/well-architected/) or [Azure](https://azure.microsoft.com/en-gb/blog/introducing-the-microsoft-azure-wellarchitected-framework/) Well-Architected Frameworks and the [NHS Digital quality review](insights/review.md). And of course, tech debt is often uncovered in the course of making changes to a system.
+Regular team retrospectives are an effective way to identify improvement opportunities and actions. Another potential source are periodic reviews using tools such as the the [AWS](https://aws.amazon.com/architecture/well-architected/) or [Azure](https://azure.microsoft.com/en-us/blog/introducing-the-microsoft-azure-wellarchitected-framework/) Well-Architected Frameworks and the [NHS Digital quality review](insights/review.md). And of course, tech debt is often uncovered in the course of making changes to a system.
 
 As discused in [Benefits](#benefits), in high level terms the opportunities for reducing waste or improving quality tend to be in these areas:
 

practices/cloud-services.md

@@ -24,7 +24,7 @@
 - Understand cloud supplier SLAs.
 - Make systems self-healing.
   - Prefer technologies which are resilient by default.
-  - Favour global-scoped (e.g. [CloudFront](https://aws.amazon.com/cloudfront/) or [Front Door](https://azure.microsoft.com/en-gb/pricing/details/frontdoor/)) or region-scoped services (e.g. [S3](https://aws.amazon.com/s3/), [Lambda](https://aws.amazon.com/lambda/), [Azure Functions](https://azure.microsoft.com/en-gb/services/functions/)) to availability-zone (AZ) scoped (e.g. [VMs](https://azure.microsoft.com/en-gb/services/virtual-machines/), [RDS DBs](https://aws.amazon.com/rds/)) or single-instance services (e.g. [EC2 instance storage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)).
+  - Favour global-scoped (e.g. [CloudFront](https://aws.amazon.com/cloudfront/) or [Front Door](https://azure.microsoft.com/en-gb/pricing/details/frontdoor/)) or region-scoped services (e.g. [S3](https://aws.amazon.com/s3/), [Lambda](https://aws.amazon.com/lambda/), [Azure Functions](https://azure.microsoft.com/en-gb/products/functions/)) to availability-zone (AZ) scoped (e.g. [VMs](https://azure.microsoft.com/en-gb/services/virtual-machines/), [RDS DBs](https://aws.amazon.com/rds/)) or single-instance services (e.g. [EC2 instance storage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)).
   - For AZ-scoped services, use redundancy to create required resilience (e.g. [AWS Auto Scaling Groups](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) or [Azure Scale/Availability Sets](https://docs.microsoft.com/en-us/azure/virtual-machines/availability)), and:
     - For stateless components use active-active configurations across AZs (e.g. running stateless containers across multiple AZs using [AWS Elastic Kubernetes Service](https://aws.amazon.com/eks/))
     - For stateful components, e.g. databases, consider use of active-active configurations across AZs (e.g. [Aurora Multi-Master](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html)), but be aware of the added complexity conflict resolution for asynchronous replication can bring and potential performance impact where synchronous replication is chosen.

practices/performance-testing.md

@@ -18,7 +18,7 @@
 ## Context
 
 - These notes are part of a broader set of [principles](../principles.md)
-- This is related to [Engineering quality-checks](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/adopt-appropriate-cyber-security-standards)
+- This is related to [Engineering quality checks](../quality-checks.md)
 - Related community of practice: [Test Automation Working Group](../communities/pd-test-automation-working-group.md)
 - See also:
   - [Quality Metrics](../quality-checks.md)

practices/security.md

@@ -13,7 +13,7 @@
 ## Context
 
 - These notes are part of a broader set of [principles](../principles.md)
-- This is related to [ARCHITECTURE-SECURITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/adopt-appropriate-cyber-security-standards)
+- This is related to [ARCHITECTURE-SECURITY](https://digital.nhs.uk/developer/architecture/principles/adopt-appropriate-cyber-security-standards)
 - :warning:Any deviation away from these security practices **must** be discussed with your security lead
 
 ## Use the NCSC guidance
@@ -83,7 +83,7 @@ The remainder of this page gives more detailed and specific recommendations to b
   - Be wary of any 3rd party JavaScript included on the page, e.g. for A/B testing, analytics
   - Pin dependencies at known versions to avoid unexpected updates
   - Scan dependencies for vulnerabilities, e.g. using [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/) or [Snyk](https://snyk.io/)
-  - Scan running software, e.g. using [OWASP ZAP](https://owasp.org/www-project-zap/)
+  - Scan running software, e.g. using [Zed Attack Proxy](https://www.zaproxy.org/)
 - **Automate** security testing — on every build if practical
   - Generate test data in a way that avoids including personally identifiable information
 - When granting roles to CI/CD tools, use different roles for the different stages in the deployment pipeline — for example so that a deployment meant for a development account cannot be performed against a production account

practices/service-reliability.md

@@ -37,4 +37,4 @@
 - Prefer serverless infrastructure where possible, and any hosts should be ephemeral and immutable (e.g. nothing gets patched or reconfigured: instead a replacement is created).
 - The only route to production is via automated deployment pipelines (see [continuous integration](continuous-integration.md)).
 - Choose technologies and architectures which foster reliable operations (see [architect for flow](../patterns/architect-for-flow.md)).
-- Make use of external good practice guides and reviews such as the [AWS](https://aws.amazon.com/architecture/well-architected/) or [Azure](https://azure.microsoft.com/en-gb/blog/introducing-the-microsoft-azure-wellarchitected-framework/) Well-Architected Frameworks.
+- Make use of external good practice guides and reviews such as the [AWS](https://aws.amazon.com/architecture/well-architected/) or [Azure](https://azure.microsoft.com/en-us/blog/introducing-the-microsoft-azure-wellarchitected-framework/) Well-Architected Frameworks.

quality-checks.md

@@ -1,4 +1,4 @@
-# Engineering quality-checks
+# Engineering quality checks
 
 This is part of a broader [quality framework](README.md) and forms a key part of the [metrics](insights/metrics.md) section.