Merging or branching in ABAP codes

[Former Member]

Hi experts!

Iu2019d like to hear your opinions about how to define a landscape or the best way of working when a system has a high concurrency in the ABAP objects in terms of development.

Iu2019m working on a project in what there are small teams with 2 or 3 members each. Each team has a distinct goal and deadline, however sometimes they must use a same source code. Certain requirements (phase 1) go to production before other ones (phase 2), nevertheless by the time a source code contains both requirements.

Other big problem is with regard to merge the codes during parallel works. I sought up on the internet and I read some articles saying that SAP doesnu2019t offer a specific tool with branching and merging features. One can at least compare different versions (new and old) in the same or remote environment. Maybe a third-party tool if exist, but itu2019d be a kind of bad solution at this moment. It should look like the SPAU transaction, whose objective is to compare and guide modifications in standard codes.

I remind Iu2019m talking about one single landscape. I wouldnu2019t like to have two or more development landscape because of diverse unwanted reasons. I guess it would create more problems than solutions.

A possible solution I found is called Feature Flag, which is known by other names too. It is a technique that shows how to maintain several distinct implementations which are controlled by a simple flag (IF clause). What are pro and cons? I donu2019t really know at all. Iu2019m still studying variety of possibilities.

We also think of using available SAP resources, such as includes and enhancement spots.

If this topic should be in another forum, please inform me the proper forum.

I will be very glad and appreciate any opinion.

Regards,

André

[ThomasZloch]

I'm not so familiar with non-ABAP methodologies, but I remember two blogs by our esteemed SCN member Uwe Schieferstein about how to logically separate developments for common objects. It is more focussed on user exits / enhancements, but you could have a look nevertheless if there is anything useful for your issue.

/people/uwe.schieferstein/blog/2008/11/11/dangerous-liaisons-in-user-exits-and-how-to-avoid-them

/people/uwe.schieferstein/blog/2009/06/16/dangerous-liaisons-in-user-exits--revisited

Thomas

[Former Member]

Thomas,

Thanks for replying to me. It is a good reference. I am going to verify this alternative, maybe using enhancement spot instead of user-exit, but the idea goes on valid anyway.

Regards,

André

[Jelena]

I'd look into using includes and enhancement spots, as you've already mentioned. I figure that's how SAP themselves deal with their development in teams.

How big of an issue it really is? Maybe it could be handled simply by task management...

[Former Member]

Jelena,

Thanks for replying to me.

In truth, there are several requirements and they are handed out to different teams simultaneously.

Really I think the solution will be Z enhancements. Before we need to define the possible points within the source code. So then every team is going to work on a specific enhancement, using its own request. As the requests are transported, the requirements will work out in productive environment. Obviously, there is variety of matters, for instance database modifications by different teams. However, I believe that every case has to be handled apart.

But Iu2019d like to interchange ideas with people who work on projects with concurrently development teams.

Regards,

André