Branching in ABAP?

[jrgkraus]

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?

[fabianlupa]

Seems like quite a lot of trouble for using branches. I guess the SAP way would be to have a dedicated SAP system for each branch.

abapGit also had a discussion on multiple branches withing one SAP system you might be interested in: https://github.com/larshp/abapGit/issues/382

[jrgkraus]

Thanks for the link! What they discuss there is similar to our approach.

Obviously for us it's not possible to use different systems. A branch is a temporary thing in our workflow. We started two weeks ago with branching and already have 8 branches on the dev system. To us the question was: accepting all the "trouble" for the sake of being able to fork, or accepting all the trouble we have with concurring requests that block each other and make hot fixes impossible. At the moment, the first alternative seems to be the better. But we are still in pilote phase...

[ceedee666]

Hi Jörg,

for me it seems you are going through all this trouble not to fork but to have different forks active at one in the same development or QA system. This is something I would never want to do.

IMO a fork would be to have one active version (current development) and an old version that might need to be maintained. For this scenario there is no need to have both versions active in the system. Instead you could use ABAPGit to create a branch (stored in the git server) and always only checkout (and transport) the branch you are currently working on.

Of cause, this does not solve the situation where multiple developers need to work on the different branches at once. For this situation IMO the "Ethan setup" is the most viable approach. However, for it to work you would have to give an own development machine to all developers and would have to need the necessary automation in place.

Christian

 

[hardyp180]

My understanding is that there is something called "ABAP GIT" which has been around for a while now, to provide the sort of functionality you are developing yourself.

 

There might even be several versions of ABAP GIT here is one:-

 

https://github.com/larshp/abapGit

 

SAP Mentor Graham Robinson is always on about trying to get me to use ABAP GIT - he gives speeches about this at SAP events - and I am convinced.

 

His speech at a forthcoming Australian SAP event is descried thus:-

 

"See how ABAP developers can work with Git-based version control systems. See how to install and use abapGit in your own ABAP development projects starting right now.

The use of distributed version control systems like Git has transformed the daily workflow of developers everywhere – but ABAP’ers have remained inside the SAP walled garden. Initiatives like abapGit break down these walls and allow ABAP developers to implement the latest development workflows, change management techniques, code sharing, code recovery, change tracking, branching, merging, etc.

We will discuss how abapGit can enhance and complement the traditional ABAP developer and change control process. And it is all OpenSource!"

 

It is ironic that at any given time, many ABAP developers are working to create the same thing, most notably a way t export data to EXCEL despite ABAP2XLSX having existed for some years now.

 

It is a communication problem!

 

Cheersy Cheers

 

Paul

 

 

[wouter_peeters]

I've read about abapGIT several times, but, what about dependencies with DDIC? I think 50% of my code will have a dependency with DDIC changes. Anyone?

[RAF]

Hi,

let my say one thing about "normal" programmers vs. ABAP.

ABAP is using a central version control system.

Other languages using (like your example) as well central and/or decentral version control systems.

If you check out all the literature about GIT and decentral versioning this could be a big challenge as well.

I think you also will get trouble finding people with experience in ABAP and decentral versioning.

Your problems sounds severe, but IMO there are some techniques (interfaces, BAdI's...) and programming philosophies (release early, release often;  AGILE...) which address these problems.

 

BR

Robert

[jrgkraus]

Thanks to all for sharing thoughts so far.

Even though the comments are all quite critical, we begin to have benefits from using this kind of branching for now. The advantage is that we can work isolated on several new features or bug fixes for the same set of programs and put them also to test. We simply tell our testing personnel to use the transaction of the branch. We even began branching on smartforms.

There are still few experiences on merging because until now, no commitment arrived which would us make merge a branch with the master. I'll come back and tell you later on about it.

 

 

[former_member150968]

Hi,

I would like to understand how did you handle user-exits and BADI's situation with this if you encounter that.

 

BR

Manish

[Szczerbowski]

Hello,

We have a 4 system chain, the extra system is a 'maintenance' second development system - it is used only for urgent fixes (because it's next to production) or when a project is locking the traditional chain. Later a change done in Maint has to be re-done in dev and transported properly thru the chain to maintain consistency.

Dev - QA - Maint - Prod

It does not solve the queue or CR order, so here we bundled CR in packs, with a delivery a few times a year.

Regards,
Michal

[tobias_topyla1]

Hi together! I am really wondering why there is a reason that the individual developers block each other!

A Workbench transport request should not be kept open for weeks. It makes more sense to release it as soon as a change is implemented. We work like that in a group of around ten ABAP developers without any significant conflicts. Daily scrum meetings established a high level of communication – furthermore we try to complete every task within less than 2 to 3 weeks, maximum of 4 weeks (monthly Agile Sprints).

What’s about trying to isolate the development objects e.g. using the Model-View-Controller concept to avoid monolithic blocks of ABAP code?

It makes also sense to utilize ABAP OO and work with the Superclass concept such aus redefining only individual methods where needed. That of course means that you will need to go away from a single REPORT listing with hundreds of lines of code.

Best regards

Tobias Topyla

<do not include phone number>

[Former Member]

Development of new features and maintenance of existing code will always collide.

Therefore we are using 5 System landscape - separate branches for maintenance and new development.

Release DEV -> Release TEST \

/|\                           PROD

Maint.  DEV -> Maint.  TEST /

Scope and duration of each release is agreed trough all departments.

Merging of error corrections into new release  partially can be automated with Correction work bench-SCWB.

 

No conflicts on transport requests, each error correction is properly tested, new development is properly tested, production system is stable between releases.

 

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

 

MfG

Raitis

[jrgkraus]

Intreresting, so the orig system of a dev object may differ in your prod system? What, if both a correction in Maint. and a new feature in Release are in the import queue of PROD? Isn't it dangerous to have two systems that can send developments to PROD?

[jrgkraus]

In fact, we fork only when necessary, User exits and BADIs are rarely in danger of multi-issue conflicts.

However, we have a procedure for user exits:

• create a user parameter for the branch number (ZBRANCH)


• at the entry include of the user exit, implement a case structure

*** include ZXEXAMPLE



get parameter id 'ZBRANCH' field lv_branch.



case lv_branch.

  when '001'.

     include zxexample_________001 if found.

  when others.

     include zxexample.

endcase.

Before forking, adjust the main include as above and release it to prod in order to not block it for further forking. The "if found" addition makes sure there are no problems in prod because of the missing branch sources.

[jrgkraus]

Often, testing of new features takes more than one week and further bug fixes are to be implemented and tested again. Until we have no OK from the testers to go live, we keep the change requests open in development to avoid overdriving by new implementations. For tests, the objects are brought with copy transports to our test system (we have only one).

In our system, we have some huge home-brewed addons that consist of  up to hundreds of classes, reports, front end programs and so on. Some central classes have a very long where-used list. They are used by many international subsidiaries and we always got a long list of requests for them. We tried to bundle them and begin developing, but as soon as we began, hot fixing was blocked by the current change request.

For now we are going on using the branching approach for two months. It's improving constantly and it seems to be working fine for us.

[Former Member]

Intersting approach, but sound like (a way) too much work for me...

 

[Former Member]

Hi All,

 

In my opinion Jörg's approach is fantastic -it comes at cost of copying objects, but it helps to keep the system landscape lean.

The alternative is to add more development systems to the landscape as Raitis' propossal, but objects should be kept in sync in both systems, otherwise would be a chaos.

ABAP Git is a good approach but I assume it does not solve the blocking-users problem, does it?

 

As Tobias pointed out, why users are blocking each other? Analysing this question might help to generate more ideas -here is mine: assign the spectrum of custom objects between developers, so each of them are responsible of a set of objects e.g.: as a developer I am responsible of 10 Z packages, maintain those and in case someone wants to operate, I should follow up, confirm, etc..

To complete this idea, these assignments should rotate every X months (in case someone leave the company or needs a backup).

Important requirement is that the communication between developers must be fluent, and the assigned objects visible (whiteboard, Trello...).

 

Regards

Pedro

[Siarljp]

SAP provides Charm (on solution manager) for managing this kind of dual track landscape. If you make a change in the application management line, then the tool directs you to make a retrofit into the AD line. The retrofit can be automatic if not application development changes have been made, or it can be more like a SPAU change, if there are conflicts. We have 2 development teams, one AM one AD, and when there are retrofit conflicts it is important that our devs communicate with each other. This process usually works fairly smoothly.

 

[Siarljp]

The problems we have are that we need multiple projects to go live in the AD line in any one release, then sometimes one project may be delated where the other needs to go live as planned, and then you need multiple working versions of both solutions, and that is where your branching suggestion may be appropriate as far as I can see. There are other alternatives though. For instance using development packages just like SAP do, and then activating the packages or deactivating them. The packages can be used for all types of development as they are tightly integrated into the standard solution, they work with global classes, BADIS, and the enhancement framework, but working with them can be complex.