How to manage branching in GCTS ?

[c_drancourt]

Dear experts, hello!

I'm looking forward to be using GCTS in my company and I already customized it, it works fine.

But honestly I have many question about how to manage architecture / branching in it, it really feels like we can't use GIT to its full extent. I'm pretty sure I missed / misunderstood something as I'm no expert in GIT.

If I consider a simple landscape : DEV, QUAL & PROD.

My understanding from the open SAP course is I have to create one repo for workbench and one repo for customizing. I saw 3 branching possibility but I see major issues on these solutions. Still I'm unable to find something satisfying.

1) One branch for each environment.+ one branch for hotfixes. Development is made on dev branche then we merge DEV with QUAL when testing is requested. When test is successfully done, we go live by merging with prod branch.

On simple cases, it seems fine but in real life it seems to not be sustainable. When feature A is developed then feature B is developed. Feature B cannot go live without feature A. I have the feeling that here we cannot work with a single repo for workbench. But in that case how should we divide our repos as there usually are interdependencies between our objects?

2) One branch per feature + one main for production. Each feature is developed on DEV and is pushed to the feature branch when development is done. The feature branch is pulled on QUAL system for testing. When testing is done successfully, the feature branch is merged to production.

Here, if feature A is developed then feature B is developed it seems to work fine: we can pull A or B in qual to test them independently. Then we can choose to merge A or B to production. But to a higher scale it seems rather complex to handle testing. If we have to checkout to the branch to be tested: we can only test on feature at a time in quality system. It cannot be acceptable on real project.

3) One branch per feature + one branch per environment. The same as previously except we can merge the feature in quality then in production when test is done successfully. It allows to implement multiple features to be tested in quality and fix the issue we had in 2.

The main issue here (and this is the biggest pain point on GCTS in my opinion) is we can't develop multiple branches in development system at the same time. If developer for feature A is developing for his branch: developer for feature B cannot checkout to branch B as it would "erase" feature A from the dev system. A solution would be to create different repositories, maybe one repo for each package would be an idea. But whenever there will be interdependencies (because it will happen of course) I think it will behave pretty poorly.

I heard about a solution using docker to mimic dev systems for each develop to be able to develop on their own system that would fix anything.

Any one has ideas, feedback on such topic? I'd be very interested.

Thanks for reading my text.

[larshp]

I did a drawing at https://github.com/larshp/two-alv-reports#full-monty on how to retain the flexibility of CTS but with git branching

[c_drancourt]

Hello Lars,

I'm not sure I understand well your propositions: I don't understand the need for the bugfix* branches as they're just the natural followup of chg* branches, I guess the bugfixes could be done on the chg* branches.

As for the merge branches, it seems to be rather complex way to work.

Still it doesn't fix the main problem: 2 developers can't develop at the same time on different branches on a common development system.

But I found a solution to this mentioned in https://github.com/nzamani/sap-nw-abap-trial-docker/

We can create a new SAP environment for each developer using docker. Developer will work on clean SAP environment customized in the way we want and will use GIT to pull their program to be changed and to save their changes on branches. Tests can be done with very basic data / using test driven development method. When automated test is done, the developer can merge their changes to the development system to test it unitary.