A branch represents a version of the solution documentation containing processes, libraries, applications, and systems.
While creating a solution, SAP Solution Manager automatically creates a production and a maintenance branch. These two branches always team-up and offer the option to separate unchangeable productive content visible in the production branch from content in the maintenance branch which can be changed. Once you changed the documentation content, you can release changes in maintenance branch and make them available in the production branch. This setup allows you to clearly differentiate between solution documentation content that is productive and content that is still work in progress. Also you follow same path like coded assets do in the technical system landscape because production branch corresponds to production systems and maintenance branch corresponds to systems from the maintenance landscape.
Hint: The maintenance branch is dedicated to small fixes in your system landscape. Its not designed for long-term or project work. Therefore it is not allowed to create sub-branches of the Maintenance branch.
Minimum branch setup:
Besides production and maintenance branch you can define further branches and sub-branches as required for project system landscapes. For instance, to repeat the 5-system-landscape example you may have an additional development system track where you prepare the next major release. In this scenario you would add another branch which corresponds to the development system track and which also reflects the solution documentation of the same. This example could be extended with further system tracks and corresponding branches. You could also add further branches that have no own system landscape but share a system landscape with other branches for instance to integrate with external 3rd party modeling tools.
The setup of branches is often driven by the system landscape design and the customer release plans.
The minimum branch setup consists of a production and maintenance branch. Further branches such as development or import branch can be added due to specific requirements.
A branch always collects all content of its parent branch. The same element has always the same identity in all branches. As a result, all changes released into e.g. the production branch become automatically visible in all child branches.
All solution documentation elements have a lifecycle status which is dependent on the branch. Solution documentation elements may be in status “unchanged”, “created”, “changed”, “deleted” or they are in “conflict”. Conflicting elements are changed in the current branch but in parallel changed in the parent branch. As a consequence, you need to resolve the conflicting elements by deciding to release or to discard the changes made. As another option you may want to mark the conflict as resolved which simply marks the element as conflict-free and so the element can be released to the parent branch.
The production branch always has a close relationship with the maintenance branch since the maintenance branch is the natural change environment for the production branch. For this reason, the maintenance branch has priority over all other sibling branches. Due to the special role of the maintenance branch, conflicting changes performed in sibling branches to the maintenance branch lead immediately to the status “maintenance conflict”. You need to resolve maintenance conflicts first as usually the changes made in the maintenance branch go first.
You should define as few branches as possible. All emergency corrections and minor release changes should be managed in the maintenance branch. The maintenance branch should be under change and request management control.
Multiple project teams should share the same branch for their work. This brings the advantage that conflicts are detected early and the project teams are forced to align their work. With this approach you can avoid that project teams work under wrong assumptions (e.g. underlying processes have changed) and other surprises and accidents. To organize the work of multiple project teams a release cycle should be applied to the maintenance branch. With a release cycle you can use requests for change (RfC) with normal changes to bundle minor developments
But there are situations where it makes sense to introduce additional branches. SAP Solution Manager 7.2 supports the implementation of S/4HANA, for example, and comes with rich process content describing the S/4HANA processes and configurations in detail. You may not want to implement all processes that come with the best practice packages at once, but want to explore and scope the best practice content first and design them before handing them over to build.
These consideration lead to the proposed best practice branch setup:
For this reason, you should use an import branch for content import and scoping, a design branch for fit/gap and definition of the customer to-be process landscape and a development branch to build the actual customer solution. To learn how the best practice branch setup can be connected to the system landscape please go here.
Also Business Process Monitoring requires a dedicated operations branch. The vast majority of our customers applies Business Process Monitoring to the productive processes and systems only.
During Business Process Monitoring setup, the processes and process diagrams should not be changed by the monitoring experts but only instrumented and activated. These activities should not interfere with the development of minor or major releases and should run independent but integrated.
Business process monitoring should be applied in a dedicated operations branch directly related to the production.
After successful implementation customers can directly apply Business Process Monitoring to ensure that the implemented processes perform as expected.