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
