Posted: 5 Jan 2017 6:44 EST Last activity: 20 Jun 2017 8:28 EDT
Why should one create new Application in order to make a branch?
Course's part "Application Design>Working with Branches" states that in order to make a branch for implement new feature - "First we need to create the team application which are built on the main application". Thus, we need to create one new application for every team (for example - TeamA and TeamB).
And only after that in CREATED application we should branch base ruleset. Why TeamA should have its own application and work in it? Why can't TeamA and TeamB work in the same app but in different branches?
After all explanation in the end of this part of study there is a info about merging. But no one word about this created application and how to handle with it.
Could you explain in context of course "Working with Branches" why here we need to create application?
I think the reason for separate applications is to be independent. If you want two teams to work on the same rules, it isnt practical to have mulitiple branches on the same application.
All operators of the same application will have acces to all branches, so if the same rule is branched to multiple branches one of the branches will have execution priority over the other due to priority of rulesets in ruleselection. This will make testing the branches seperately difficult.
The first thing that I would like to mention is that creating a team application is not a hard requirement or constraint in order to create branches. You can try it on your PVS exercise system but you can essentially create a branch with the HRApps (Open the application > Branches section) or with any application. A key to delivering successful Pega implementations is adopting best practices, and I think that this team application that you mention is included in the course as a best practice.
Creating team applications applies to larger and interrelated dev projects and teams (SCRUM of SCRUMS for example). It merely adds an additional layer of abstraction when managing and coordinating "parallel" development efforts. It enables a more modular and scalable software development cycle and for smoother dev ops in general.