Improve BUILD & RUN documentation (#831)

CHANGELOG.md

@@ -4,6 +4,8 @@
 
 Note: Can be used with `sfdx plugins:install sfdx-hardis@beta` and docker image `hardisgroupcom/sfdx-hardis@beta`
 
+- Improve [BUILD & RUN documentation](https://sfdx-hardis.cloudity.com/salesforce-ci-cd-hotfixes/)
+
 ## [5.1.0] 2024-10-11
 
 - hardis:project:deploy:smart: Fix to adapt stdout checks to output of `sf project deploy start` in case code coverage is ignored

docs/salesforce-ci-cd-hotfixes.md

@@ -6,7 +6,11 @@ description: Learn how to handle hotfixes in a sfdx-hardis CI/CD environment, ha
 
 ## BUILD & RUN
 
-Except for projects in maintenance that contain RUN only, a project is separated into 2 sections: the BUILD and the RUN
+Except for projects in maintenance that contain RUN only, a project is separated into 2 sections:
+
+- the RUN stream: Fast cycle, to often deploy minor changes and fixes
+
+- the BUILD stream: Project cycle, to build more advanced features and enhancements, that require User Acceptance Testing
 
 ![](assets/images/ci-cd-schema-build-run.jpg)
 
@@ -22,14 +26,16 @@ Is it important that **major features or enhancements are not tested directly at
 
 ### THE RUN
 
-Daily maintenance of the production Salesforce org must be very reactive, the RUN level will allow you to **deploy patch versions**.
+Daily maintenance of the production Salesforce org must be very reactive, the RUN level will allow you to often **deploy patch versions**.
 
-As we usually can not wait for the next minor or major version to be deployed in production, projects need a way to quickly deploy hot fixes into production. That layer is called the RUN, and is exclusively about **preprod** and **production branches**.
+As we usually can not wait for the next minor or major version to be deployed in production, projects need a way to quickly deploy hot fixes into production. That layer is called the RUN, and is exclusively about **preprod** and **main** branches.
 
 To summarize, you will **publish at RUN level, but also at BUILD level**, so when the BUILD will be merged in the RUN, **there will be no overwrite triggering regressions**.
 
 The **hotfix process** is the following:
 
+_Note: in this example, we merge directly in **preprod**, but in more advanced organizations we can define a branch/org **uat_run** as intermediate layer before merging to preprod_
+
 - IMPLEMENT **HOTFIX** _**(1)**_
 
   - Create new task with **preprod as target when prompted**, named `my-very-hot-hotfix` for example
@@ -40,12 +46,19 @@ The **hotfix process** is the following:
 
   - Create Pull Request from `my-very-hot-hotfix` to `preprod` & merge it after controls (do not select “delete after merge” )
 
-  - Create Pull request from `preprod` to `production`
+  - Create Pull request from `preprod` to `main`
 
-  - Merge `preprod` to `production` after control checks are green.
+  - Merge `preprod` to `main` after control checks are green.
 
 - RETROFIT IN **BUILD LAYER** _**(3)**_
 
-  - Create Pull Request from `my-very-hot-hotfix` to `integration` & merge it after controls
+  - Create a sub-branch to `integration`, named `retrofit-from-run` for example
+
+  - Using Git IDE, manually merge `main` (or `preprod`) branch into `retrofit-from-run`
+
+  - If there are git conflicts, solve them before committing
+
+  - Create Pull Request from `retrofit-from-run` to `integration`
 
-  - If there are issues (conflicts…), you can solve them directly in  my-very-hot-hotfix then complete your retrofit PR to integration
+  - Merge the Pull Request into `integration`: your retrofit from the RUN to the BUILD is over :)
+    - You might refresh dev sandboxes if your retrofits have lots of impacts