Technical Articles
Fully supporting CI in ABAP AS
Introduction
At the recent #DSAGTT20, SAP showed a few slides regarding in the area of continuous integration and ABAP:
https://twitter.com/PanzerDominik/status/1227274686750478338/photo/1
https://twitter.com/WachterSascha/status/1227254813542559745/photo/1
I did not attend the event, so the below might be out of context.
Continuous Integration
Continuous Integration(CI) is a word that can mean a lot of different things to different people, to me its something about providing feedback to the developer for each change, the feedback must be reliable and provided within a timely manner.
A change could be whenever the development is saved, or a commit, or something else, its really up to the development environment, which is a different topic. The developer needs the information to determine if its okay to push the change to a wider audience.
Also exactly how the development is deployed to the CI system is a deployment topic. The scenarios below can be set up using the classic transport system.
- Code Inspector / ATC
- Coverage results
- Unit tests
- Integration tests
- eCATT
- UI tests
- Performance tests
- Metrics
Scenario 1 – Baseline
Let’s take a common setup with development, test and production. The developers do development in the development system, the test system is used for manual testing.
Assumption: All organizations have a requirement for doing manual exploratory testing, even if all testing is automated, the QAS system cannot be scrapped.

Scenario 2 – Use QAS for CI
For each change done by the developers, the change is deployed to QAS and CI is run. When the results have been reported the change is reverted.

For ABAP systems its difficult to do a proper rollback of the objects. The unit and integration tests might change data in the system(they should not), so a full database rollback is required to have fully reliable results.
This means that the system cannot be used for manual testing at the same time, for each change the developers make the system is changed. Alternatively, specific time-slots are allocated for CI and some other for manual testing.
All-in-all this ends up with an automated process for breaking the QAS system, instead of avoiding errors via automation.
Scenario 3 – Add new CI system
So, to not disturb manual testing in the QAS system, the CI run can be moved to a different server. CI runs in CIS system, and manual testing is done in QAS,

Scenario 4 – Scalable CI
In scenario 3, assuming CI is run for each change run one by one.
And assuming each CI run takes 10 minutes, and each developer does 30 changes per day, with 2 developers = 60 changes = 600 minutes = 10 hours.
It should be possible to determine the feedback for the change while developers go get coffee, so more CIS systems are required. Typically hardware is cheaper than wages, so one CIS system per developer is an easy solution, but expensive?

Scenario 5 – Containerization
Instead of having a lot of idle systems, spawn a new CIS system using containerization and deploy the changes, run CI.
This way there will be a common baseline for everything, and no need to do any reverts, just spawning systems instead.
This can give reliable results in a timely manner, but I still have not seen anyone doing this setup yet, as its difficult to get everything running, and tough decisions have to be made to determine which baseline to use. If its a large container snapshot, hot standbys can be setup to respond fast.

Scenario 6 – Run inside DEV
Going in the other direction, setting up new infrastructure is time-consuming and expensive. How about running the CI inside the existing DEV system? This will sacrifice some reliability as the changes are not tested in isolation, but partner solutions exists that can help reduce this risk.

Scenario 7 – Multiple active versions
According to the slides, SAP has support for development and maintenance within the same system on the road-map.
This is possible today, but with multiple systems, so I assume the new innovation will be supporting this in a single system, and at the same time. So the ABAP kernel will have to support multiple active versions at a time. When(if?) this is implemented, the CI can run within the DEV system, just on the version with the changes done by the developer.
This, however, raises a lot of other questions regarding the maintenance of data, database isolation etc.

Guess this will never happen, instead what the slides refer to is probably a possibility to change between active versions. If there is more than one developer working in the area switched to development or maintenance on the same system, they will have to coordinate when to do one thing or another. I.e. it still makes sense to have separate development and maintenance systems.
Scenario 8 – One system per developer
As suggested by Ethan Jewett back in 2016:
http://searchsap.techtarget.com/answer/How-can-I-use-Git-and-GitHub-for-SAP-software-development
http://searchsap.techtarget.com/tip/Implementing-modern-practices-in-an-ABAP-development-shop
Give one development system to each ABAP developer, this will help to do the development and unit tests in isolation. But still, CI should be run centrally on aligned infrastructure and configuration.

Scenario 9 – Front-load outside ABAP AS
Performing CI on ABAP application servers is required but might be an extensive setup.
For tasks like checking whitespace, a complete ABAP AS is not really required, multiple steps can be added in the CI pipeline, and once initial checks have been made, the ABAP CI run can be started.
abaplint is one free option that exists, it can run on Linux, so it hooks easily into GitHub Actions / GitLab Pipelines / whatever. If doing development in other languages than ABAP this is a typical setup for development, so it might be able to run on already existing infrastructure. Also note that this does not require any commercial licenses to run, so it can be used for open source development.
Results can be unreliable, but the setup is easy and cheap.

Conclusions
CI in ABAP is difficult, choose wisely among cost, reliability, speed, complexity etc. they have large consequences on the development process and infrastructure.
Fully supporting continuous integration is not just getting some results to the pipeline, like getting code into git is not devops.
ABAP containerization is required to fully support CI, without it it’s not possible to fully support continuous integration.
Also make sure to check out https://blogs.sap.com/2020/02/20/weve-finished-our-renovations-our-new-ci-cd-best-practices/
Some snippets from the help pages:
«According to the slides, SAP has [planned] support for development and maintenance within the same system on the road-map.»
*raises eyebrows* Sounds too much out of some sci-fi world to be believable. How does one merely keep two “base versions” or “branches” of code (edit in: actually, not only code, but all "development artifacts" and “client independent” customizing) in one ABAP system, for starters..?
yea, as mentioned above, I think it should not be read as it says
but instead as it will be possible to switch between active versions in one system, like what is possible to do manually today, or today using abapGit
This is a misinterpretation of Martin Bredy 's slide. With gCTS you can still only have one git branch active in a system at any given point in time. It is just easier to switch branches compared to the current transport-based practice. But this is nothing new. You can do the same with abapGit as well.
Ok, but… if it’s so easy to “spawn” new DEV instances (and they are kinda needed then, in order not to disturb others while “pulling in” a few months old version to do a bug fix) why would one then not simply spawn one semi-permanent instance on which everyone develops new release? Which eventually becomes the next maintenance instance, on release, and so on. If one has to deal with (too) many maintenance instances, maybe?
The challenge for us on two transport track development landscape has always been merging bug fixes into new release… “Manually” without ChaRM (or whatever it’s been renamed to now), – using plain SCWB + SM30 table compare + occasional transport and changing object’s source system. It works, but: 1) not every artifact is supported by SCWB; 2) folks still forget to merge on occasion. Which is why stuff like Notes 2687151, 2843795, 2706774 adding support for more things to SCWB (after all these years…) =
. While SAP investing in “Git here”, “continuous meh” there = just mildly intriguing 
Cheers,
Jānis
Hi Lars,
I attended this (very interesting) session and the Q&A afterwards.
SAP is currently experimenting with multiple scenarios. The most promissing one in my opinion is the following:
No SciFy but reality 🙂
But that all is not "in einem System" anymore, strictly speaking..? /:)
No (like in every other languages / Dev environments)
As I wrote above, with gCTS you can still only have one git branch active in a system at any given point in time. It is just easier to switch branches from dev to test or whatever in the same system, compared to the current transport-based practice. But this is nothing new, just a bit less special snowflake.
“but reality”: is it possible to see it in action and try it out?
"Martin Brady" (Dev at SAP) was the guy, who hosted the Q&A session at DSAG TechDays in Mannheim. Maybe you can try to contact him (sorry, don't have any contact data)
It's Martin Bredy . Contact as usual: firstname.lastname@sap.com
Hi Lars,
I really like your concise, structured blog! Some comments:
Scenario 7 : multiple active versions of some component in the same ABAP system at the same time will probably not become reality any time soon. With gCTS you can basically achieve the same as with abapGit: off-load sources to a separate repository so that you can more easily switch branches of that component on a system. This has of course limitations when it comes to data migration triggered by DDic changes, which cannot be reverted (easily).
Scenario 9: Whatever defect you can find locally offline saves you time and resources later in your pipeline when you deploy the changes to an ABAP system for further testing. For the sake of completeness, there are already other tools like abapLint making use of that principle, for instance, the ABAP plugin for SonarCube: https://docs.sonarqube.org/pages/viewpage.action?pageId=6389836
Cheers,
Christoph
thanks, yes, make sure to investigate the market, I dont want to mention any specific commercial products. And also check it works in the development flow / process.
https://blogs.sap.com/2020/03/03/ci-cd-in-abap-an-outside-in-view/ ...not exactly a response, but my slightly different view on the same topic, based on an earlier internal survey I wrote. Enjoy! ?
As we have many scenarios, but scenario 9 is kinda easy. One question, which one tool can be the best for ABAP unit testing or integration testing. As for Code Coverage, ABAPLint is working fine.