Hi RodrigoA6031, Can you clarify the 2 reasons you've mentioned with an example?
1. What is the need for an 'immutable' version? If Team A & Team B are working in their own corresponding branches and if Team B is complete and ready to release, cant they just merge their changes to the base application and release without impacting Team A?
2. How does having separate Team applications help faster delivery?
However one other advantage I can think of by having a team application is from an access standpoint as this will enable creation of specific AccessGroups and hence provide the needed isolation.
1. A simple example: imagine that we have two teams working over the same base version. One is changing a flow, and the other need to fix a bug in the same flow. If they are working in the same application. The bug fixing may be compromissed by the flow changes. The called immutable version would be something like a base version for multiple development streams.
2. Not a faster delivery, probably more assertive. Agility is more about saving time than speed.
Plus the number of branches defined against a single application should not become excessive for performance reasons. The PDN article below describes a layered approach that leverages multiple built-on applications.