situation:
Case A: Dev/Prod
- we have 2 BUs: "Dev-BU" and "Prod-BU"
- ACN development is solely done on "Dev-BU"
- potential difficulty: the client may make changes directly on "Prod-BU"
- testing is conducted on "Dev-BU"
- branches (Uwe Völlger - please review) (ignore upper half)
- feature/ — changes to "Dev-BU", no automated deployment
- master — upon commit, deploy diff to "Prod-BU"
- branch rules (like in the above picture)
- no direct commits to release + master branch --> only via PR
- feature -> master
- feature branches created off of master branch
Comments from Uwe:
That is fine
End comments from Uwe
Case B: Dev/Qa/Prod
- we have 3 BUs: "Dev-BU", "Qa-BU" and "Prod-BU"
- ACN development is solely done on "Dev-BU"
- potential difficulty: the client may make changes directly on "Prod-BU"
- testing is conducted on "Qa-BU"
- branches (Uwe Völlger - please review) (ignore lower half)
- feature/ — changes to "Dev-BU", no automated deployment
- release/ — upon commit, deploy diff to "Qa-BU"
- master — upon commit, deploy diff to "Prod-BU"
- branch rules (like in the above picture)
- no direct commits to release + master branch --> only via PR
- feature -> release -> master
- feature branches created off of release branches
- release branches created off of master branch
Comments from Uwe:
Here I would do it differentyl. The normal development happens in the "lower half". Release branches are created as late as possible - that means only if there are parallel releases. This typically happens when bugs must be fixed found during a QA phase while development happens already on the next release. This helps to create as less branches as possible, as each branch also means merges, that might result in conflicts and a lot of work.
So branch rules would be
- no direct commits to release + master branch --> only via PR
- Outside of QA phase:
- feature -> master
- feature branches created off of master branches
- When QA runs in parallel to development
- eature -> release -> master
- feature branches created off of release branches
- release branches created off of master branch when QA starts
End comments from Uwe
Uwe Völlger: falls mehr envs nötig werden würde ich zu branches übergehen die nach den envs benannt sind.
Comments from Uwe:
I would like to avoid env-specific branches. It would work, but would create much effort. What's about the idea which we have in SF classic: we define a release (basically a range of commits) and deploy the same to QA BU and more BUs. That of course means the BUs must basically the same, and differences must somehow covered.
End comments from Uwe
Der klassische develop branch könnte bei langfristigeren projekten aber genauso zur anwendung kommen? ziel outcome sollte sein, dass die branching strategie möglichst simpel ist, damit auch nicht versierte nutzer schnell die logik dahinter verstehen UND schätzen
Comments from Uwe:
+**+Ja, das würde auch für weniger agile Projekte passen. Im Prinzip ist das dann auch nicht viel anders als ohne den Branch. Details im Umgang stehen in https://kxdocuments.accenture.com/Contribution/130a8ab6-37c0-43b9-9a9f-a18b16f03e79
End comments from Uwe