Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
jrgkraus
Active Contributor
In my company, we are running SAP ERP since the early nineties and the system is full of self-made add-ons that are maintained by a team of abap developers. The traffic of request for improvements or error corrections is high and we often run into blocking conflicts for repo objects.This made me think of setting up a procedure that allows us to work on different features of one program independently like "normal" programmers can do using version control software.

So we started branching in ABAP.

Our approach is yet new and immature, and that's why I'd like to discuss it here. I appreciate any kind of participation!

The approach



  1. Determine a 3 digit number to identify the branch. We therefore have a central tabular document where all branches are put in.

  2. Make a copy of the repo object and include the branch number in the name of the copy. We do it by filling the original name with underscores and using the last three chars for the branch number.
    So a program
    ZP_SOME_PROGRAM
    will be copied to
    ZP_SOME_PROGRAM______001 for branch 001

  3. For global classes, it can be very annoying making a copy, because every usage of the class has to be redefined then changing the reference type of the variable. Therefore, you must copy the user of the class and follow that chain until the main program. This can lead to an explosion of needed copies for one branch. Therefore, we use subclasses for the branches. Then, only the code where a class is instantiated has to be forked whilst the other utilisers can go on with the super class type.

  4. As a consequence of the item above, classes should not use private attributes and methods, for they can not be accessed in a sub class. So step by step we are transforming our classes changing private objects to protected.

  5. When a new feature has been approved, the branch is merged with the master branch (the original objects) using split screen editor (for sources) to apply all changes for the feature of the branch. For other objects like screens and gui status the merge has to be done manually.

  6. For hot fixes, the master branch is changed directly. Hot fixes should go live shortly so the period where the master branch is blocked by a change request remains as small as possible.


I hope you got the idea. What do you think of it?
18 Comments