Why does ABAP not support branching and merging?

Having read Stuart’s interesting blog about the lack of branching, merging and tagging in SAP ABAP, I felt compelled to reply, but have chosen to do so in the form of a blog instead of using the post comment facility as I’ve rather a lot to say on the matter.

I think that this blog reflects the view of many developers whose background is primarily web or bespoke application development. People often forget that SAP is not a development environment, but rather an extensive application with its own built-in enhancement framework. This allows for both system configuration and application enhancement through the development of bespoke reports written in ABAP or functional enhancements through the development of new user interfaces or through modifying standard SAP delivered screens. The SAP application has been around since the early 1970′s and since then has been developed and enhanced to the point where current estimates state that there are between 238 and 250 million lines of ABAP code.

So, firstly we are not comparing like for like, this is not a clean sheet development environment, so the rules change slightly. In anticipation of the likely response from the “Non SAP” camp, yes the SAP framework does allow and indeed encourage bespoke developments that complement the pre-delivered solution, and Yes there are organisations like G3 who develop solutions on top of the SAP layer to add value and plug gaps.

In short, it’s true, branching and merging doesn’t exist within the SAP ABAP framework, but there is one trick that ABAP has over other environments, namely that the source code is transported through the system landscape, Dev – Quality – Integration – Live, and activated on each system. In the application world you may compile code into libraries that are deployed into your respective environments, and for the most part, this code is secure, and not modifiable. I can see that the likes are HTML, JavaScript and for example PHP could arguably be modified in the Live world, but any compiled object could not be touched.

The movement of source code across the system landscape is important as SAP is more than just a code base, there are thousands of “objects” that could potentially be different in each environment. The process of activation in each system is a way of ensuring that all the pieces fit together. If a table is changed to add a new field which is then referenced in code, when the code is transported, the Activation process in the live environment will check the references to ensure that the table field exists, and would result in an activation error if it doesn’t.

So what is the solution to the described problem, and how have other companies managed these issues? I can only speak from the end user perspective, where we have had to support a live system whilst developing the system further or even the process of upgrading which is taking the problem to a whole new scale.

Let’s get the upgrade out of the way, as this is easily dealt with. In my experience, when you are upgrading your SAP system to the latest version, you take a lot of time and care. All bespoke developments and enhancements to SAP objects have to be tested along with configuration. Upgrades of this scale are often bigger than pure functionality changes, and often incorporate upgrades or complete changes to the underlying Basis stack, or NetWeaver versions. (I’m probably using incorrect terminology at this point, but it’s not important in the scope of this response). To facilitate this, most companies will set-up a new system with the latest NetWeaver environment and transport all configuration and code changes onto the system for testing. Any changes made in the live landscape development box are either transported to the upgrade system, and incorporated into testing, or manually applied. As a rule, most companies freeze development during the upgrade process and only fix critical bugs, so the problem is not too dramatic.

So, how do manage a support environment and development environment on a single landscape? Not easy, and a strategy has to be agreed and then stuck to. In the past we have used the option of making changes to the quality environment directly through the “repair” function. This allows us to fix the bug in a controlled way and keep an audit trail through the transport request. At this stage we can either apply the same change in the development environment, or leave it until later. If you take the latter route, you will have to list all of the repairs in the quality environment through and easily written report and then go through a manual merge into development.

SAP provides the developer with a tool to compare versions of the code across the landscape. It compares code side by side and highlights changes (in the same way you would in Subversion if there were conflicts). What it doesn’t do is the merge for you. This is something that a programmer with the inclination could easily remedy, but in truth, the art of merging code is more than just looking for conflicts or changes to code, but understanding the reason and benefits of the change. It could well be that the problem has actually been addressed in the new development but through a slightly different or better approach, so automatic merging would no doubt cause problems.

If you are not prepared to or not able to use the repair approach, and you don’t have access to a separate development environment, you are left with the painful option of self management. In reality this means very careful management of transports and code changes, considering naming new versions of programs and functions with an identifier either suffix or prefix, but this approach can’t easily be extended to data dictionary objects such as tables. In truth, this sort of development should not take place on the “client” box or landscape, but should be done off-line in a separate landscape and only deployed to the client landscape at agreed drops or releases. This allows you to make support changes in the client landscape.

So to answer the question, can ABAP handle branching or merging? In short No, or at least not in the Subversion sense of the term. Should it or could it? I doubt it could and suggest it would be a brave man that attempts to implement it. The dependencies across configuration objects means that the concept of branching in SAP would be incredibly complex as it’s not just lines of code we have to keep track of, but system configuration, data dictionary objects etc.

It wouldn’t be too hard to write a few programs to take snapshots of code at a point in time. You’d probably have to do this at a Development Class, or Package as they are now called, level to ensure you catch all objects, but it’s easy to write. There are already ABAP programs out there that allow you to download and archive code and dictionary objects, so It’s not unreasonable to take this a step further and create snapshots. This would, in theory, provide you with a quick way in which to restore your code base to a point in time, although I’d be very cautious of reverting table changes in an automated way as the potential data loss could be dramatic. I’d be interested in seeing how Subversion handles dictionary object version management. I’d be interested in hearing from anyone who has tried this.

Lastly, the statement “I’ve yet to meet an ABAP developer who knows anything about version control” I suspect what this means is that he hasn’t met an ABAP developer that can describe the merits of Subversion style version management. Version management within SAP ABAP, is a critical tool in the ABAP developers arsenal, and coupled with the transport mechanism allows us paint a picture of the system at any given point in time. It’s not pretty, it’s not easy, but it is doable. ABAP developers know about version management, they just might not be familiar with the concept of branching. The one area that the Subversion approach wins is the ability to tag or snapshot at a given time, a tool that is sadly lacking, but not to hard to develop.

Let the debate continue. I’m sure many of you out there in the ABAP world will have worked through these sort of issues, so please respond if you have an angle on this.