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.

• The installation into an existing Jenkins instance can be done with the integrated plugin manager in the web UI of the Jenkins server or by using the Jenkins CLI install-plugin command.
  
• The source code can be found at: https://github.com/jenkinsci/abap-ci-plugin
• And here is the link to the actual documentation : https://plugins.jenkins.io/abap-ci/

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.

• https://github.com/lechnerc77/ABAP_CI_PIPELINE_BASE and
• https://blogs.sap.com/2017/11/11/continuous-integration-in-abap-using-jenkins/

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.

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:

• Executing ATC checks after each activation (ABAP OpenChecks, Eclipse AbapCi Plugin, AbapLint)
• Running Unit tests after each activation (Eclipse AbapCi Plugin)

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.

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

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.