Handling multiples Releases - Best Practice for Branches Creation

[former_member611427]

Hi All,

We have implemented Process management in Solman 7.2 SP05 and is currently being used by project team for documentation purposes. Currently we have PRD;MAINT and DEV branches defined. Post go-live, all the changes along with documentation will be moved to PRD & MAINT branches. Both Maintenance and Project Implementations will happen in single ECC landscape (D-Q-P) in single track.

Going forward, there will be multiple projects with different release timelines that will be executed along with support activities. In this regard, what would be the best practice/approach post go-live:

• Do we need to create a new branch for each release by project teams?
• Can we use one DEV branch to handle all future releases by project teams? if yes, how to make sure the WIP work of Rel 2 doesn`t move to PRD branch with Rel1 go-live??
• If we have to create one branch per release, what will happen to that branch post go-live?? Can we archive or set it to closed status so that no further changes happen in that branch (Client doesn't want to delete the branch post go-live)

At this point in time, client is not inclined to usage of ChaRM & Focused build.

Appreciate if you can share your experiences and suggest any best practices for handling above scenarios.

Regards,

Mohammed

[former_member190969]

Hi Mohammed,

thank you for this very good question of yours. I would say the use of Change Requests would be the gold standard to cater for multiple releases. You can also use parallel development branches to do this Dev1, Dev2, Dev3 all as children of Production Branch (another variant would be to have them as children of a dev-master branch to consolidate changes of different projects and solving conflicts before releasing to production. The difference is the following: When you use different change requests and you have to change the same element or document already existing in Production in two projects, the first change that is released, releases the change to prouction. You will just get a warning on release, that this document or element is part of another change. When you use parallel branches you will get a conflict on release. This means either project 1 or project 2 will have to discard their changes, so the other can release. Everything that can be merged is merged though, so if project 1 changes the description and project 2 changes the owner of a process there is no conflict. Conflicts are likely on document content. This means manual comparison of document versions to merge them. There is no tool support on this.

After the release of a such a Dev1 branch it should be deleted because it holds no data at all anymore. You should still be able to see in History that an element or document has been created or changed in Dev1 because history data are not deleted.

Kind Regards
Andreas

[former_member611427]

Thanks Barbara for the wiki link. I have already gone through the link and our existing setup is based on this similar lines. However, it doesn`t talk about handling multiple releases within the same landscape...I am looking more specifically for the scenario mentioned above and the queries thereby...

Appreciate if you can provide any guidance on my queries..

Regards,

Mohammed

[former_member189541]

Hello Mohammed,
For suitable best practices, see SAP Solution Manager WIKI - Process Management > Branch basics and best practices.
Kind regards, Barbara