Introduction
A few weeks ago I had a discussion with fred.verheul and volker.wegert3 on the missing support for branching in the current ABAP version control system.
The following tweet by Fred sparked the whole discussion:
Clearly bitten today by impossibility to work in multiple branches in #ABAP. Welcome to the 20th century! Oh, wait...
— Fred Verheul (@fredverheul) November 3, 2015During the course of the discussion between Volker and me the focus shifted a little bit to the area of system landscapes for custom development. At the end of the discussion I promised to write a blog to allow more detailed discussions of the topic.
@vwegert @fredverheul An issue where I see no solution is a central development for different customers with different productive versions.
— ceedee666 (@ceedee666) November 3, 2015Due to the holiday season I finally came around writing the promised blog.
In the following sections I will try to explain some of the challenges I'm frequently facing in certain scenarios. I would be interested in discussing if other people here on SCN face similar challenges and which kind of tools or system set-ups they are using to solve them.
Challenge 1: Multiple Development System
The first scenario I frequently encounter is the multiple development systems scenario. My customers usually use a multiple development system to test and / or implement some new complex SAP functionality. For example, in order to test and implement the SEPA (https://en.wikipedia.org/wiki/Single_Euro_Payments_Area) delivered by SAP a second development system was established in the system landscape at some of my customers. The reason for using a second development system is usually that projects in overlapping areas and different projects schedules take place in parallel. Therefore, a second development system is used to allow the projects to progress independently. Most of the time this development system also contains some data to allow to perform first tests with the new functionality. Therefore, it is usually not only a development but also some kind of QS system. The resulting system landscape is shown in the following figure.
The second development system is basically a very heavy weight approach for creating a branch (https://en.wikipedia.org/wiki/Branching_%28version_control%29). However, This approach my lead to problems soon as the development from the second development system need to be integrated back into the main line of development (i.e. development system 1). The reason is that development artefacts might have been changed in two development systems in parallel. Consequently, there is a need to merge (https://en.wikipedia.org/wiki/Merge_%28version_control%29) the different versions of the development artefact. As no tool support for this merge exists (besides the possibility to compare different versions) in the standard SAP version control system this a quite error prone manual task. Basically each development artefact changed or created in development system 2 needs to be manually checked if a conflicting change occurred. The problem becomes even worse when conflicting changes in customizing tables occur.
To remedy these problems we usually set-up the transport routes in a scenario with two development systems as shown in the following figure.
All transport request released in development system 1 are automatically imported into development system 2. The development team working in the development system 2 are responsible for merging conflicting changes whenever they occur. In the development system 2 only very few transport request are created (ideally only two, one for development objects and one for customizing). Once the changes from development system 2 need to be merged back into the main line of development these transport requests are released and imported back into development system 1. There, the changes objects are added to a new transport request and transported to the QS system for testing.
With this approach basically a merge is performed with each and every transport released form development system 1. Therefore, the overall merge is broken down into small steps. Nevertheless, the merge is still a manual task.
From my experience the approach works quite well. However, the situation can easily become more complex if more then two development system are involved. In this case a hierarchy of development systems would need to be defined. Also more complex system landscape, e.g. consisting of SAP CRM, SAP ERP and further external system can further complicate the situation.
Challenge 2: Custom Development for different Target Landscapes
The second challenge is related to developing for different customer landscapes in a central development system. In this situation developments from a central development system are deployed into 1 to N system landscapes (cf. following figure). This is, for example, the case if developments in a customer name space (/XYZ/) are deployed into different target landscapes. In this scenario problems occur in the context of bug fixing as well as major further development.
Problem with bug fixing
Es an example consider the following situation. Version 1.2 of a central component has been deployed to production. During productive use an error is encountered in System Landscape A, fixed in the central development system and transported to the QS system in System Landscape A for testing. During this test a further bug is encountered and fixed in the central development system. The result is that Version 1.4 of the software exists in the central development system, System Landscape A has Version 1.2 deployed to production and Version 1.3 in the development and QS system. Additionally Version 1.2 is deployed to the whole System Landscape B. The whole situation is depicted in the following figure.
If several centrally developed software components as well as several target landscapes are involved the situation quickly becomes quite unmanageable. Currently, the SAP transport system offers no tools to manage those scenarios. For example, there is no possibility to create a revision tag (https://en.wikipedia.org/wiki/Revision_tag) for a set of development artefacts and transport this revision information through the system landscape. In order to cope with this problem we currently roll regularly out all centrally developed software components to all target landscapes. In the context of the utilities industry in Germany this is possible as regulatory requirements lead to the implementation of new service packs each 6 month. In this context major system and integration tests are required anyway. Therefore, we "misuse" the required tests to roll out new versions of central components to all target landscape. This way the same version of the central component is deployed to production in all target system landscape. This eliminates the need for tracking the deployed software version. Furthermore, due to the tests required to deploy the service pack no additional test efforts are required for the central components. However, if no regular service pack implementations would be required this approach would not be possible.
Problem with major further development
The whole situation becomes even worse when a major further development needs to occur. Basically two approaches are possible to perform a major further development. Either, the existing development artefacts are changes or all development artefacts are copied to a new package and the further development occurs in this package. The problem with the first approach is that one basically loses the ability to perform bug fixes for the previous version. For example, consider the scenario depicted in the following figure.
A major development has been performed in the central software component (Version 1.2 to Version 2.0). However, the Version 2.0 is still tested in System Landscape A. If now a bug occurs in System Landscape B in Version 1.2 of the central software component there is no suitable way to fix it. Either one would need to roll back all the development in the central component to Version 1.2. However, due to the missing release tags and tool support this is in any large project virtually impossible. Or the bug fix needs to be performed in the System Landscape B and the bug fix needs to be manually ported to the Version 2.0 of the central software component.
The alternative of copying all artefacts to a new package is equally bad. While in this case bug fixing in the System Landscape B is still possible now two components with possible a lot of duplicated code need to be maintained. This is for complex components also not an option.
What are your experiences?
In summary, I currently have only partial solutions for the scenarios described above. I would be interested in discussing if you have encountered similar issues? And if yes, how you solved them. Are you using any third party software or do you only use SAP standard tools?
Christian
- SAP Managed Tags:
3 Comments
