Picking up Branches from another team's Dev App

Pega-as-a-Service
, , , ,
1

Question related to the behaviour I’m describing in Pega Infinity 23.1.2 (I assume this behaviour is the same in other recent versions):

I always thought that by defining separate DevApps on top of multiple parallel (production) Apps, one would create isolation between the teams working on each of these DevApps. This thought seems not quite right when it comes to branches for shared layers/apps.

When looking at the list of Rulesets in my Profile in Dev Studio on client’s dev environment I see I am picking up all the branch rulesets for all the Rulesets that are in my App Stack, even the branches that are not in the DevApp App Rule I’m logged into.
So, say I’m in DevA App on top of A App containing an A Ruleset. and there is a DevB App on top of B App containing a B Ruleset and both sit on top of shared C App containing a C Ruleset. And assume there is a C_Branch_Story123 and a B_Branch-Story123 in DevApp B defined because team B is working on Story-123 which requires a change in App/Ruleset B and C.
Being in DevA, I am picking up the C_Branch_Story123 but not the B_Branch_Story123. This is happening because App/Ruleset C is in my stack and App/Ruleset B is not.

So my question is: is the picking up of another team’s shared layer branch intended behaviour or is this unintended (a defect?)

This behaviour can have an impact on the validity of my test results in DevA App. I’m doing tests that include the change for Story-123 in App/Ruleset C that team B has made in their Branch in the DevB App (if that change plays a role in my logic.)
It can also impact testing on the test environment if my branch is merged and deployed before the branch for Story-123 is merged and deployed. Something that worked in Dev environment might fail because the update for Story-123 is not in the test environment yet.

Of course with disciplined dev management someone should spot a dependency between what I am doing in DevA and what team B is doing in an underlying layer but you would have to look in your Profile in Dev Studio to spot which shared layer branches you’ve picked up unknowingly because I cannot look into the DevB App to see what branches they have created and which Rulesets they have made changes in.

2

@SCHEJ all I could find was the Pega Academy explanation:

For Pega 8.2:

Developing in parallel by branching rulesets

For Pega 24.x

Parallel development

Modular enterprise reuse

App Studio

If the documentation does not shed any light on the matter I would suggest that you log a support incident for this so that our Engineers can investigate if product is working as documented or not.

Branches and Branch Rulesets

Merging Branches into target Rulesets

Best practices for using multiple built-on applications

Understanding best practices for version control in the DevOps pipeline

3

@SCHEJ I’ve create a INC- ticket in MSP to get a formal answer from product management/engineering. I will post the outcome here once I receive the answer.

4

@SCHEJ I see that you were unable to replicate the issue this week

Things you tried:

Switched Apps a few times to see if that triggered the problem but it didn’t.

Please can you mark this post with accepted solution if you have no further opportunities to replicate the problem?

As always please reopen the official INC you logged if you need to reopen and provide screenshots whilst you try to save in a Branch that should not be accessible.