CI/CD in SAP – Introduction to CI/CD for SAP Teams

Testing should NOT be just another checkbox to mark

Testing SAP is sometimes seen as just another checkbox to mark. This “checkbox” approach to testing is a real problem, because it limits how we perceive the value of what can be achieved with modern testing approaches and solutions.

But contrary to that view, testing isn’t just “checking if it works” (usually on a strictly limited scope). When orchestrated correctly, testing can mean that you’re validating the solution under all circumstances. Which makes QA checks with users a quick formality, rather than a tedious and disliked process. And as a Head of Product at Int4, I firmly believe that defect-free go-live should be a standard, not a glimpse of luck.

But of course, it’s easier said than done with the current market dynamics.

There are two seemingly opposing factors 

Most business communication between SAP-companies and their partners or other various parties is executed using electronic, automated channels running on integration platforms – which makes testing more complex than ever before. Yet the business demand for innovation is also great. 

In this context, traditional release cycles (for example once every quarter) might not be enough to keep pace with the agility and speed that your customers, business stakeholders or end-user might expect.

And that’s exactly why the concept of modern CI/CD in SAP might be worth exploring. Because many businesses can reduce the reliance on manual testing, minimize risk, and deploy changes in a more agile manner. My name is Marcin Gałczyński and it will be my pleasure to be your guide into this topic!

What is CI/CD in the context of SAP?

The acronym “CI/CD” stands for “Continuous Integration and Delivery. So as you can see, there are two main components of this concept:

• Continuous Integration – meaning that the source code changes are checked against the existing codebase and the promised features are working
• Continuous Delivery – standing for immediate deployment of approved changes in the production environment.

In short, CI/CD in SAP means using modern development practices – like automated testing, version control, and streamlined release pipelines – to continuously integrate new code and swiftly deliver it into production. But can it really be achieved?

Continuous Integration and Delivery – is it really possible to implement in SAP?

And while it might sound like an approach that’s hard to implement, you’d be amazed at how many different enterprise companies explore it. Amazon – for example – is able to deliver changes into their landscape several times per hour, without compromising quality or introducing downtime!

Now, if you’re a release manager for a corporation running your business on SAP this might seem as a fantasy or a dream – being used to bi-weekly or monthly release cycles for the business changes, and observing how the develop-test loop is running quite often for much longer periods. One might think applying CI/CD principles should improve this, but is it really possible to do it in a SAP environment? To answer this question, we need to look a bit into technology.

SAP-Specific challenges to CI/CD: different technologies mean different approach

From a high level perspective, a modern SAP-based application would be based on two components.

• The business logic – offering data access and manipulation layer, within the integrated S/4HANA environment. This would be written in ABAP and developed in a dedicated environment.
• The Fiori part – contemporary UI technology, executed in the user’s browser, interacting with the S/4HANA backend.

Fiori vs. ABAP: Key Differences in CI/CD

You have probably already heard about Git-based solutions like Bitbucket, GitLab or GitHub. And if you haven’t – it’s probably a good time to do your research, because this software source control system plays a pivotal role in CI/CD implementation. And the reason for that is simple: it’s a foundation for managing multiple concurrent software versions.

Mind the gap!

There’s a gap between the usual Git application and the S/4HANA world: the ability of developers to work locally.

For Fiori applications, this is very easy. The browser part can be written and executed on the developer’s computer. But for the ABAP component, that’s not possible. Because the runtime environment for ABAP consists of a relatively big software installation running on a server with much larger resources than a typical laptop can provide. 

In the end – ABAP components layer (like the OData), which exposes the data and allows for its management, must be written and immediately deployed to the dedicated server which is common for all developers in the organization.

Recognizing these differences is crucial for implementing a robust CI/CD pipeline in SAP that accommodates both Fiori’s local development flexibility and ABAP’s server-based requirements. If you’re interested in a more technical outlook, there’s an excellent article written by Lars on SDN which covers this topic that you can access here.

Challenges and Workarounds for ABAP

So what you’re getting with ABAP is a variant of “Continuous Integration”. As the code changes are validated and compiled against the shared codebase. But unfortunately, there is no option for more than one person to work on the same development object at the same time. But with a good enough organization (e.g. by using includes) this limitation can be solved.

And yes – it is already there. The way that ABAP platform is designed enforces the Continuous Integration. And actually, it did so even before the term was actually coined. But the challenge remains – there is no localized environment for every single developer. Meaning – they all have to share one environment.

So if you’re a person managing the software lifecycle for an SAP organization, your situation can be summarized like this:

• You’re like possible to implement CI/CD for the end-user based Fiori components,
• You can benefit from the enforced CI (Continuous Integration) for ABAP-based components,
• You now need to plan and organize development, considering the platform’s overall limitations.

At so at this point, it’s important to get back to testing

The Role of Automated Testing in the SAP CI/CD

While the acronym CI/CD does not have a “T” inside, testing is a mandatory element of this concept.

If you’re familiar with corporate system change control processes, surely you’ve run into something called CAB – a Change Approval Board. Where a strict process is followed, and test evidence is a must-have element needed to approve the release of a change to production. In Continuous Deployment things are no different. 

Following a successful integration step (where you prove that the code contribution compiles and integrates with the overall system), a set of automated tests are executed before the deployment step. Failure of automated tests results in blocking the process until the issue is resolved. Here’s an in-depth explanation of the Automated API Testing in SAP:

What should immediately stand it is that the tests need to be written first, before the development even really starts. Otherwise the automation of release for the CD would not be possible.

CI/CD in a business reality – how to minimize a need for users’ validation?

In a corporate environment, there is another factor introducing complexity. Depending on the specific business area, validation by a business user is usually expectedFor audit reasons or at least – for peace of mind. But it can also be legally binding, as it is for controlled businesses, just to mention pharmaceutical companies as a representative example.

So on one hand, you’d like to introduce automation to reduce time to market. But on the other hand, there are business users who must be a part of the release process. And it’s probably not a surprise for you, that their time, dedicated to keeping business running and profitable, is a limited resource. And the experience shows that it’s hard to get by the cost-generating IT department.

The automated testing component surprisingly answers this challenge.

How can automated testing possibly help?

In an ideal scenario it might be possible to present automated test results in a way that the business users will simply accept. Instead of asking them to perform the test, they might be able to get the job done in a fraction of the time. But of course – that’s the ideal. Which might not always be possible. 

And if that cannot be done, then the automated testing could be used to ensure that the tested deliverable will be accepted by business users on their first attempt. Because if the test library is comprehensive enough, it might simply cover all the scenarios.

Automated testing can also be safer.

In traditional circumstances, we have no reason to believe that the business user perform tests thoroughly. Considering their time limitations and lack of IT experience, its very likely that the test will only check the expected positive scenario. As the business tester might not have the understanding needed to test negative scenarios or put the solution to a stress, by using invalid data or counter-intuitive scenarios to check all possible routes where things could go wrong.

What can you do NOW to get closer to the “CI/CD dream” in your SAP organization?

While direct implementation of the CI/CD principles seems to – indeed – be a far away dream for the SAP-centric companies’ IT departments, there are certain ways to work on shortening the release cycle and improving time-to-market, with its principles. To sum these up:

• Implement continuous integration for Fiori based developments

• Structure ABAP work in a way allowing concurrent developments on common code

• Implement automated testing to reduce business involvement and potentially limit end-user approval testing to formal confirmation of accepting automated tests results

If you’re locked into the usual release process – implementing the ideas above will probably not change that. But it will definitely reduce time spent waiting on business user availability, resolving conflicting developments and most importantly – remove the repeated cycles of development and testing due to insufficient testing by developers.

And the smoothness of the development process that this would result in – could give your organization the ability to run the Change Approval Board meeting every other day, for just 15 – 20 minutes – and enable system changes much faster with higher quality and limited risk to the production system. Which honestly – might be good enough.

Risk vs reward when it comes to Continuous Integration and Delivery

There are two terms that are bugging every manager – being “risk” and “ROI”. Not surprisingly, they boil down to quality and time. But for me – this is where automated testing really shines. Because automated testing has the potential to overtake any manual efforts.

For example, Int4’s enterprise customers are easily executing 1000+ (thousands or more!) test cases for a single interface, thanks to automated test case creation and execution. Even with an experienced tester running each test in 10 minutes, it would take a person around 200 working days to repeat that, while automation executes in several hours.

Can you even create this many test cases in SAP?

While executing thousands of test cases might sound great – in a typical scenario, such test case library could take months to create. But thanks to solutions that are already used by some of the largest companies in the world, you can do it pretty-much on an autopilot:

More test cases = higher quality

And why so many test cases? This is where quality comes in, guaranteed by coverage. Even having only hundreds of test cases, ideally based on current production data, makes it very likely to ensure that this sample represents more than 95% of the business scenarios, including edge cases that would otherwise slip to production rendering business delays and losses

By automating tests, we can ensure high coverage, reducing risk. Also – automated tests run quickly, improving the return of investment as the time (money) spent on developments and testing by business is much shorter.

Look ahead!

While I firmly believe that the above recommendation stands, keep your eyes open! SAP, with the move to BTP platform, seems to more and more comprehend the gap between modern release approaches and what’s possible on the ABAP platform.

Look at new developments of the gCTS and see how the ABAP-Git project gained traction. It’s not unlikely that the ease of starting up a BTP ABAP server and SAP’s investments in its crucial backbone technology will open up their platforms for fully adopting CI/CD principles.

So a quick summary for you…

If you just want to get a quick set of points – here are a few pointers to guide your actions:

• CI/CD in SAP is absolutely possible, especially with Fiori-based UIs and well-designed principles for working with the ABAP code.
• ABAP development requires different planning but is moving toward modern, Git-based workflows (gCTS, ABAP Git).
• Automated testing (like with Int4 Suite) is critical for bridging technology gaps and reducing business involvement.
• Small steps toward automation – continuous integration for ABAP and Fiori, robust unit/integration tests – pay off in reduced risk and faster releases.

And if you’re looking for an automated testing solution…

Look no further. Simply get familiar with the Int4 Suite. A powerful testing solution built specifically for the automated SAP API Testing.

Here’s a video that will help you understand the basics:

And if you’re ready – feel free to book a demo of the Int4 Suite so that you can see for yourself, how this solution could prove useful to your organization: