Skip to Content
Technical Articles

Continuous Integration and ABAP – Jenkins the missing link

Summary

Jenkins is one of the standard tools for Continuous Integration. As introduced in my presentation of the SAP Online Track an Open Source native Jenkins Plugin is now also available for ABAP to apply Continuous Integration or Daily/Nighly Build components easily on an ABAP development system.

A%20native%20Abap%20Jenkins%20Plugin

abap-ci – A native Jenkins Plugin to  enable Continuous Integration for ABAP

 

Introduction

What is the intention of yet another plugin?

There are plenty of working solutions to enable Continuous Integration for ABAP. Related to Jenkins I want to point out two projects – which served also as base for the creation of the native Jenkins plugin – thanks for them to Christian Lechner and Chairat (Par) Onyaem.

And of course there is already a Project “Piper” implementation to connect to an ABAP Cloud instance and not to forget the future will bring us with gCTS hopefully a full CI/CD system for the ABAP ecosystem.

All these tools are more powerful than the actual version of the native abap-ci Jenkins plugin. But I think to get started with Jenkins, ABAP and CI practices, fully scripted or entire based on “Infrastructure as a Code” approaches are not easy start – although they have indiscussable advantages.

The new, native Jenkins plugin should lower the barrier to start with Continuous Integration and ABAP but is not a replacement for the existing tools. 

The main target of the abap-ci Jenkins Plugin is to provide an “easy to start tool” to enable Continuous Integration for an on-premise ABAP development system.

Is Continuous Integration with ABAP even possible?

Due to the nature of ABAP – the integration into the Netweaver Database and Application Server –  there are some constraints when it comes to Continuous integration – the “Special snowflake blog” points these points out very good.

In my point of view Continuous Integration works quite well for ABAP development systems. Well not without a bit of pragmatism.

Continuous Delivery and Continuous Deployment I will exclude in this blog – but my latest information is that the future direction of SAP here is to also support them fully with gCTS.

In this blog I will focus on the core Continuous Integration functionality as it was originally defined by Jez Humble and Martin Fowler.

Continuous%20Integration%20Certification%20Test

The Continuous Integration Certification Test – a good essential definition

 

“Continuous Integration Certification Test” is rather a buzzy title for an incredible simple but exact description about all the essential targets of Continuous Integration.

One can argue whether point 1 is already fulfilled or not (see for example CI/CD in ABAP – An Outside-In View) and how to establish point 2 (see for example Fully supporting CI in ABAP AS) but in the end the fulfillment of the main goal of CI environments counts and that is to catch bugs and code smells early in the development process – also known as shift left principle.

In my opinion to get out the most value of the shift left principle it should be applied whenever possible directly when the code is written. This means mainly:

The standard system setup of an ABAP landscape is in most cases currently one development system where several ABAP developers continuously make changes. That means that during the day when people are working on features in the ABAP system, its not guaranteed that the complete ABAP development system is always in a stable state. That’s maybe the biggest challenge when applying standard CI systems to ABAP.

Especially for ABAP I think a Daily or Nightly Build is very helpful which checks for existing bugs and code smells in the stable timeframe overnight – and here Jenkins with its easy to manage scheduled jobs and hopefully the introduced abap-ci plugin in the next chapter is the perfect solution.

Jenkins by the way works perfectly together with GitHub, thus other scenarios like triggering the Build Pipelines after an abapGit push by GitHub Weebhook are possible setups for an automated Continuous Integration system for ABAP.

Getting started with the plugin

To use the abap-ci Jenkins plugin there are only 5 simple steps necessary:

  1. Install the plugin using the Jenkins Plugin Manager, and restart Jenkins.
  2. Go to the global configuration page (Manage Jenkins > Configure System).
  3. Find the AbapCi Plugin Section and specify the connection info for your ABAP development system.
  4. Create a new Jenkins job for an ABAP Package of your ABAP Dev System (a freestyle project or a pipeline project)
  5. There is no step 5 … you are already done 😉

 

Below you see two screenshots how the Jenkins Jobs for ABAP look like. First for a traditional Jenkins Job, then for a Jenkins Pipeline.

 

Continously%20running%20Unit%20tests%20and/or%20ATC%20checks

Continuously running Unit tests and/or ATC checks for an ABAP package with a Jenkins build step

 

Continuously%20running%20Unit%20tests%20and%20ATC%20checks%20of%20an%20ABAP%20package%20with%20a%20Jenkins%20pipeline

Continuously running Unit tests and/or ATC for an ABAP package checks with a Jenkins pipeline

 

More details and the latest documentation can be found at: https://plugins.jenkins.io/abap-ci/.

 

Does Continuous Integration for ABAP pays off?

Release cycles get shorter and shorter – they can hardly be handled without a minimum degree of automation. In ABAP systems we are coming more and more to Bimodal IT landscapes:
Fiori and ABAP, Java/.Net and ABAP, SCP and ABAP, Excel and ABAP 🙂 )

Of course ABAP is special and in some areas of the ABAP environment applying Continuous Integration is not or only hardly possible. For example UserExits or Enhancements tightly coupled to the database.

But in some areas of the ABAP environment Continuous Integration practices can increase the quality of the ABAP code and save a lot of time.

Lets take an example: Visualizing the throughput in a car factory based on an ABAP system: 

Ideally in the backend of the system the workplaces of the production plant, goods movement, …are customized. When this is accomplished there should not be anymore frequent changes. Rebuilding the plant or reorganizing the assembly lanes does simply not happen each month.

On the other side the requirement for the frontend changes a lot. This week the management likes to see these KPIs, the next week the other KPIs.

Fortunately the frontend is normally lightweight – means does not have a lot of dependencies, contains persistence data and not a lot of business logic. Thats the ideal setup for automated builds, deployments and also important if needed fast automated roll backs of failed deployments.

In the upper area of the backend there are usually objects that contain mainly logic, in our case that would be for example ABAP classes or CDS views which calculate the KPIs. This is the ideal area for applying Continuous Integration practices – and the ideal point to start with the abap-ci Jenkins plugin.

To sum it up. I think Continuous Integration practices in the ABAP area are possible and also valuable . But not in the whole stack – the ideal part to start with Continuous Integration is the part of the ABAP system that contains the business logic.

Continuous Integration for ABAP needs to address the uniqueness of ABAP in some points. But mainly its about a  commitment to Unit Tests, Clean Architecture and Clean Code. And of course it needs tools like abapGit or the native Git Client for ABAP in the Cloud, Jenkins, ABAP in Eclipse and maybe the abap-ci Plugin is the missing link which enables a complete Continuous Integration environment for ABAP.

9 Comments
You must be Logged on to comment or reply to a post.
  • I always get really confused because “continuous integration” means different things to different people.

    The wikipedia defintion says it is all about developers working on their local machines and then merging their code every so often – that matches the diagram in your blog. I can see how that applies to ABAP in the Cloud, but not to the traditional ABAP system where everyone is changing the core system all the time (hence the unstable nature you speak of, and anyone testing in a development system with data moaning about TYPELOAD_NEW_VERSION dumps).

    Someone else here on SCN the other day said that CI was all about moving things to production, and ABAP was no good as you could not roll back a transport request, and a structure change took ages in the live system and a whole bunch of other things, which meant you could not keep pushing changes to production all through the day in a safe manner, even if they had sufficient unit tests. Then someone said that was not CI that was CD.

    You mention above the concept of a “nightly build” in an ABAP system. As I understand it in a Java system such a build is all about making sure all the dependencies in each class are compiled without errors. What would be the ABAP equivalent? Are we still talking about code inspector and unit tests or something else like checking for non-obvious syntax errors?

    An example of a non obvious syntax error is if I was mad enough to add a new obligatory parameter to a public method of a class, and that class would compile fine, but all the programs that called it would now have syntax errors.

    Or are you talking about something else entirely?

    Cheersy Cheers

    Paul

    • Hi Paul!

      Yes there is often a confusion about Continuous Integration (CI) as it is often mixed up with CI/CD. The core of CI in my opinion is to “continuously integrate your work to a shared baseline”.

      When applied on a Java environment with the small foodprint of Java programs I think there is no discussion that the above definition means indeed “continuously integrate your working copies to a shared baseline”

      But with ABAP I have the experience that the difference between “work” and “working copies” in most cases decides if you can introduce parts of CI practices or struggle in the initial setup.

      Thus in the ABAP world I think we have to be pragmatic and come back to the core intentation of CI. To find release breaking bugs and problems early in the development process.

      To get pointed out this core intention and highlight the difference between CI and CD I regulary stick to the following definition of Atlassin. 

      Like Lars Hvam points out in the conclusions of his blog https://blogs.sap.com/2020/02/20/fully-supporting-ci-in-abap-as/ CI in ABAP is difficult, but he also shows various approaches which support at least parts of a Continuous Integration landscape.

      The Nightly Build (in the context of this blog I use it as “Nightly Test and ATC run”) I brought up because Continuous Integration is seen mostly tightly coupled to a versioning system like Git, as changes in the versioning system is normally the trigger to start a CI run.

      The important thing is that the main target of the Nightly Build is the same like for CI: “ensure that …no bugs have been introduced” – quote of Wikipedia.

      I am convinced that the future will bring us a fully compliant CI approach to a common accepted definition for ABAP – ideally out of the box. Whether its gCTS or also maybe all the “crazy projects” which have been done in the CI area of ABAP from the community sum up to a perfect CI system

      So hopefully I am not talking about something else entirely, but of cours differently 🙂

      Cheers, Andreas

      /