Skip to Content
Technical Articles

Our Journey with SAP ERP DevOps Part 1/2

Software development teams outside of the SAP ecosystem are years ahead in leveraging DevOps ideas, automated testing/continuous integration, and modern version control tools (i.e., GitHub) to realize tremendous productivity and quality gains. Containerizing ERP would be a considerable step towards accessing these advantages for ABAP development. We decided to take a fresh look at community efforts to run SAP ERP inside a container. We were excited by the prospect of productivity gains and the new development workflows we could achieve — if only we could spin up ERP instances in a matter of minutes.

Spoiler alert: we got there, and it takes 3 minutes to get a fresh ERP instance ready to go! We created a DevOps workflow around this capability that accelerates development and will ensure we always deliver tested solutions.

This blog post is part 1 of a 2 part series on our journey with SAP ERP DevOps. Part 1 focuses on the functional aspect of our process, and part 2 focuses on the technical challenges.

Disclaimer: SAP does not yet support running ERP or S/4 on containers. 

What can we do with SAP ERP in a container?

Our goal is to install ERP once, perform basic setup, and then capture this system’s snapshot as a docker container image. This image will allow us to quickly replicate our baseline ERP instance by starting a docker container. Armed with this building-block, we next add our ABAP code into ERP by connecting to our git repositories using abapGit. SAP is now ready for development, automated testing, or any other use we can imagine. 

Use Case 1: To Each Their Own (An Instance of SAP for each Developer, that is!)

ABAP developers are often forced to develop code in a dev system that has been subjected to untold rounds of experimental changes during previous projects, may be shared by developers on concurrent projects, and is often a shared resource among colleagues who may be working on additional aspects of the same project!

We do development work inside ERP running in a container. This practice eliminates uncertainty stemming from unrelated changes being made in shared systems. Developers can also be confident that their results will be reproducible in their colleagues’ systems. Since everyone works from a common container image with identical versions, enhancement packs, and base configuration (matched to the customer’s requirements), no time is wasted resolving compatibility problems or struggling to reproduce results on another system.

Giving each developer their containerized ERP instances has even more benefits:

  • No risk to testing out experimental changes – it’s easy to revert the SAP system to a known state
  • The SAP instance can be run locally or in the cloud, and each developer can run as many systems as they need
  • Improvements to the base configuration are easy to share with all developers – pull the latest docker image!

Use Case 2: Is the Phrase “SAP DevOps” Still an Oxymoron?

We strive to use software development best practices. When working with ABAP code, we are constrained by the tool compatibility with SAP. Here is our (in our opinion modest) list of fundamental ideas for modern DevOps workflows:

  • Keep the code in a git repository instead of in the SAP database (we use GitHub)
  • ABAP code commits must pass automated tests before they can be merged
  • Developers can run automated tests locally to aid in development (tests should be fast so that developers can iterate efficiently)
  • Test results must be deterministic

After analyzing how we could implement these ideas, we determined that we needed a container that would quickly bring up an ERP instance to build the DevOps workflow we wanted. After some container experiments, we settled on a design that bundles a fresh ERP install with these customizations:

  • We apply basic config typical for a manufacturing company, add several materials and customers for testing
  • We pre-load abapGit along with a small suite of custom Remote Function Calls (RFCs) that allow us to choose additional software repositories to install via abapGit. We can specify code repositories to install when starting the container or call RFCs to do so after the container starts
  • We have configured our SAP databases to auto-grow. This is important because we’d like to size the DB’s such that they are just about to hit their auto-grow thresholds in order to minimize the size of the final docker image
  • When our container starts, it automatically starts the database and then the application server

With this configuration, the container is not only helpful in developing ABAP code, but we can also use it in automated testing. The git repositories can contain more than just code; they can define SAP Gateway services and include test data sets for automated testing.

Our automated testing procedure looks something like this:

1. A developer modifies ABAP code in an SAP container instance. They create a feature branch to hold their work. When the code is ready to be merged, they create a pull request from the feature branch in GitHub.

2. Each pull request triggers an automated test of the latest code (via a webhook). The code to be tested is the main branch’s HEAD with the feature branch applied on top.

3. The repository also contains the automated testing configuration. In our case, it describes Kubernetes Pods to start up and a series of commands to run inside of them. One of the containers inside the Pod runs our SAP ERP image.

4. We run a series of RFCs on the SAP instance to instruct abapGit to install the version of the code being tested, along with specific versions of any other repositories that are dependencies.

5. The results of these tests are reported back to GitHub and are required to succeed before the pull request can be merged (check out GitHub’s Branch Protection Rules).

Resources

abapGit is open-source software that provides a 2-way connection between git repositories (GitHub in our case) and an SAP ERP instance.

Installing SAP NW ABAP in a Docker container blog post

 

 

10 Comments
You must be Logged on to comment or reply to a post.
  • Cool stuff, thanks for sharing

    Can you elaborate on whats included in "3 minutes to get a fresh ERP instance ready to go"? 

    Instantiating a new virtual machine on a hyperscaler, installing docker, downloading the image, starting the image and SAP system?

    • It takes us a long time to build the Docker image, but we can start new containers in 3 minutes once we have the image.

      We run an unattended SAP installation to create the image, but that process takes about 4 hours. This lengthy process is acceptable since image creation should only happen once for each combination of SAP/component versions.

      We take the 130GB docker image and split it into a 5GB docker image + 125GB GCP persistent disk snapshot. When we start a container on Kubernetes, we have to create a fresh persistent disk from that snapshot (it takes ~1.5 minutes). Then we start the container, and after another 1.5 minutes, SAP is ready to go. The upcoming part 2 has more details on this process. ​

  • Not only does this sound awesome, it also sounds like fun! 🙂

    And I love how this approach would replace developers insecurity with confidence, related to the untold rounds of experimental changes during previous projects and also parallel projects.

    • Fun, frustrating, infuriating. 😂

      It was worth it though, the result with this DevOps approach is just better software.

  • Sounds amazing!

    I had something similar started a couple years ago but stopped at a semi-manual stage (I can start a new instance in about the same time from the command line, but is 2 separate commands for cloning a volume and starting a container, no k8s, license only works on the server the image was created on,...) and stopped there because further automation was easy, except I had no idea how to make the license working on a random server and without breaking any licensing agreement.

    How did you sort that?

    • I had issues applying the license when spinning up multiple containers. I noticed the issue was due to the self-assigned hostname/IP address for the container. Try changing the hostname to match the FQDN used during SAP installation.

        • Got it. It would be nice if SAP offered official support. We also experienced some strange behavior during several steps of the process.

  • Hi Nestor - Re your comment 'Disclaimer: SAP does not yet support running ERP or S/4 on containers' - is there a roadmap especially with SAP Cloud Foundry/Diago to realize this? tx