Update shift left post

Author: johnaohara

content/post/shift-left-on-performance/index.adoc

@@ -1,6 +1,6 @@
 ---
 title: "Shift Left on Performance"
-date: 2023-01-10T00:00:00Z
+date: 2025-03-04T00:00:00Z
 categories: ['performance', 'methodology', 'CI/CD']
 summary: 'To speed up delivery of software using CD pipelines, performance testing needs to be continual performed, with the correct bounds to add value to the software development process'
 image: 'shift-left-banner.png'
@@ -58,7 +58,7 @@ This has the benefits of;
 * Reduce cost to fix
 * Reduce test & deploy cycles
 
-Performance issues are generally more difficult to fix that functional testsfootnote:[Citation Needed], performance testing should be "Shifted-Left" in the same way that functional testing has been
+Functional issues are typically easier to fix than Performance issues because they involve specific, reproducible errors in the software's behavior; therefore, performance testing should be "Shifted-Left" in the same way that functional testing has been
 
 '''
 
@@ -68,12 +68,16 @@ In the traditional Waterfall model for software development, shift left means pu
 
 image::shift-left-waterfall.jpeg[]
 
+source: https://insights.sei.cmu.edu/blog/four-types-of-shift-left-testing/
+
 ==== In the Agile world
 
 For continually delivered services, "shifting left" incudes an additional dimension;
 
 image::shift-left-agile.jpeg[Agile Shift Left,,,float="right"]
 
+source: https://insights.sei.cmu.edu/blog/four-types-of-shift-left-testing/
+
 Not only do we want to include performance tests earlier in the dev/release cycle, we also want to ensure that the full suite of performance tests (or any proxy performance tests footnoteL[Citation needed]) captures performance regressions before multiple release cycles have occurred.
 
 == Risks in the managed service world
@@ -97,19 +101,18 @@ image::shift-workflow.png[Agile Shift Left,,,float="right"]
 
 In a "Shifted-left" model;
 
-* Repository Bots allow performance engineers to initiate *Upstream Performance Tests* against open Pull Requests
+* *Code Repository Bots* allow performance engineers to initiate *Upstream Performance Tests* against open Pull Requests, returning comparative performance data to workflow that the engineer uses in the day-to-day job.
 * *Integrated Performance Threshold* tests provide automated gating of acceptable levels of performance
 * *Continual Performance Testing* allows for analyzing trends over time, scaling, soak and chaos type testing, asynchronously from the CI/CD build pipeline
 * *Automated Regression Detection* provides automated tooling for detecting catastrophic performance regression related to a single commit, or creeps in performance degradation over time
 
 Continual analysis is performed by experienced engineers, but the process does not require manual intervention with each release.
 
-Engineers are free to focus on implementing features and not worry about regressions.  When regressions are detected, the information they need to identify the root cause is readily available, in a suitable format.
+Engineers are free to focus on implementing features and not worry about performance regressions.  When regressions are detected, the information they need to identify the root cause is readily available, in a suitable format.
 
-== Repository Bots
+== Code Repository Bots
 
-INFORMATION:: 
-Repository Bots initiate performance tests against PR's. Their purpose is to allow engineers to make a decision on whether to merge a PR or not. The results need to be actionable by engineers. Profiling data should also be provide to allow engineers to understand what their changes are doing
+Code Repository Bots initiate performance tests against PR's. Their purpose is to allow engineers to make a decision on whether to merge a PR or not. The results need to be actionable by engineers. Profiling data should also be provide to allow engineers to understand what their changes are doing
 
 Receive report & analysis of impact of changes to key performance metrics
 
@@ -123,7 +126,6 @@ Allow automated capture of profiling data of system under load, allowing enginee
 
 == Integrated Performance Thresholds
 
-INFORMATION:: 
 The aim of Integrated Performance Tests is to determine whether a release meets acceptable levels of performance with respect to customer expectations, not to capture changes over time. The results need to be automatically calculated and should provide a boolean Pass/Fail result.
 
 * Pass/Fail criteria - the same as functional tests, the performance should be either be acceptable, or not-acceptable
@@ -136,7 +138,6 @@ The aim of Integrated Performance Tests is to determine whether a release meets
 
 == Continual Performance Testing
 
-INFORMATION:: 
 The aim of Continual Performance Testing is to perform larger scale performance workloads, that can take time to perform.
 
 These tests can include;
@@ -172,4 +173,4 @@ Other tools that can help product teams with performance related issues are;
 * *Performance Bisect*: perform an automated bisect on source repository, running performance test(s) each time to automatically identify the code merge that introduced the performance regression
 * *Automated profiling analysis*: AI/ML models to automatically spot performance issues in profiling data
 * *Proxy Metrics*: System metrics captured during functional testing that will provide an indication that a performance/scale issue will manifest at runtime
-* *Automatic tuning of service configuration*: Using Hyper-parameter optimization to automatically tune configuration space of a service to optimize the performance for a given target environment/workload
+* *Automatic tuning of service configuration*: Using Hyper-Parameter Optimizationfootnote:[https://github.com/kruize/hpo] to automatically tune configuration space of a service to optimize the performance for a given target environment/workload