Skip to Content
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.

Elements of a CI pipeline might include:
  • 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.

16 Comments
You must be Logged on to comment or reply to a post.
  • 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:

    Thereby, you can detect errors as quickly as possible and prevent integration problems before completing the development.

    Continuously committing even smaller code changes into the main line and beginning to do so at an early stage of your development process is the key principle of continuous integration.

    Execute scenario tests on machines that are comparable to the final production landscape.

    Include fast-running tests directly into your CI builds and run more time-consuming ones later.

  • «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:

    • local development (every developer has it’s own mini S/4 system on his laptop (yes it works with standard laptops)
    • gCTS, own development branch, CI server starts docker image of empty S/4 + special testdata
    • merge to master branch which triggers import to QA (or Prod, depends on the scenario)

    No SciFy but reality 🙂

  • 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.

  • 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.