AWS prescriptive-guidance documentation change
Summary
Updated document title in breadcrumb and modified reference to resilience testing patterns with minor editorial changes
Security assessment
Editorial changes to testing recommendations maintain existing security-related content about fault injection but don't introduce new security guidance or address vulnerabilities.
Diff
diff --git a/prescriptive-guidance/latest/resilience-lifecycle-framework/pre-deployment.md b/prescriptive-guidance/latest/resilience-lifecycle-framework/pre-deployment.md index 045f96942..58f6a63b3 100644 --- a//prescriptive-guidance/latest/resilience-lifecycle-framework/pre-deployment.md +++ b//prescriptive-guidance/latest/resilience-lifecycle-framework/pre-deployment.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Resilience lifecycle framework](introduction.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Resilience lifecycle framework: A continuous approach to resilience improvement](introduction.html) @@ -19 +19 @@ Integration testing is the process of testing that a well-defined component of a -We recommend that you design integration tests that specifically test the resilience patterns you have implemented, such as circuit breaker patterns or load shedding (see [Stage 2: Design and implement](./stage-2.html)). Resilience-oriented integration tests often involve applying a specific load to the application or intentionally introducing disruptions into the environment by using capabilities such as [AWS Fault Injection Service (AWS FIS)](https://aws.amazon.com/fis/). Ideally, you should run all integration tests as part of your CI/CD pipeline and ensure that you run tests every time code is committed. This helps you quickly detect and react to any changes to code or configurations that result in violations of your resilience objectives. Large-scale distributed applications are complex, and even minor changes can significantly impact the resilience of seemingly unrelated portions of your application. Try to run your tests on every commit. AWS provides an excellent set of tools for operating your CI/CD pipeline and other DevOps tools. For more information, see [Introduction to DevOps on AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/introduction-to-devops.html) on the AWS website. +We recommend that you design integration tests that specifically test the resilience patterns you have implemented, such as circuit breaker patterns or load shedding (see the [design and implement](./stage-2.html) stage). Resilience-oriented integration tests often involve applying a specific load to the application or intentionally introducing disruptions into the environment by using capabilities such as [AWS Fault Injection Service (AWS FIS)](https://aws.amazon.com/fis/). Ideally, you should run all integration tests as part of your CI/CD pipeline and ensure that you run tests every time code is committed. This helps you quickly detect and react to any changes to code or configurations that result in violations of your resilience objectives. Large-scale distributed applications are complex, and even minor changes can significantly impact the resilience of seemingly unrelated portions of your application. Try to run your tests on every commit. AWS provides an excellent set of tools for operating your CI/CD pipeline and other DevOps tools. For more information, see [Introduction to DevOps on AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/introduction-to-devops.html) on the AWS website.