We’ve been applying DevOps for SAP to our product development and couldn’t be happier with the results. Below is a high-level overview of how we implemented DevOps for our team, and I hope it helps move the practice forward and gain adoption within SAP.
If you’re not familiar with containers, you can think of them similarly to virtual machines. A virtual machine allows you to run an operating system, and a container enables you to run a single program. In our case, the goal was to run SAP ECC in a container. One advantage of containers is that they are quickly replaceable. For example, you can break your system and start a new container in about three minutes. This is possible because containers are based on images. Images are like “snapshots” that store the system in a known state.
Each developer, functional resource, or tester can use containers to run their own SAP system. Running SAP in a container environment provides system isolation, so work never impacts others. Isolation is a massive advantage as you don’t have to worry about object locks, overwriting data someone else was using, or creating inaccurate results if your work depends on theirs.
There are several options to run containers, but one of the most popular is Docker. We built our containers using Docker mainly due to the large community and trusted name.
You receive a requirement to format all the phone numbers in your SAP ERP system to match the country’s format for that customer. You start a container based on “SAP ERP 3 years of data” and write your first draft of the logic. You test it individually for 12 phone numbers, and it works. Then you decide to run it on all 125,000 customers and realize that it deletes every other phone number.
In a traditional scenario, this might make any developer panic. However, container isolation means you only impacted the current container you are running. You decide to remove that container and start a new one, again based on the image “SAP ERP 3 years of data,” so all of your customer phone number data is back to the original state after 3 minutes. Time to try again.
The keen reader might wonder, “what happens to my code if I remove a container?” Any changes you make to a container are wiped when you remove it. The new container is a replica of the image you use, introducing a new problem – how do we save our code?
abapGit to the rescue! abapGit is an opensource git client for ABAP. It allows us to use a tool such as GitHub for source code management. Instead of transports, we use abapGit to manage our code changes inside a container. There are countless tutorials on git and GitHub, so I will only cover the basics.
Git uses the concept of repositories which are very similar to SAP packages. Each repository corresponds to an SAP package. By default, your repository has one main branch considered the definitive branch. You can create feature branches to experiment with before committing it to the main branch. When you begin working on a feature or bug fix, you create a branch (e.g., my-feature-branch.) Any code changes you make are committed to this branch. The branch is now part of the repository and visible to others who have access. Now you can start a new container and pull your feature branch into the new container.
As a developer, reducing the cycle of code, test, debug, repeat is crucial. The reality is that testing is difficult, and the feedback loop when humans are testing is far too long. Automated testing helps reduce this cycle and deliver better software.
Testing requires an organizational change. ABAP unit testing is not new in SAP but is rarely used. Using automation to enforce unit testing can train developers to follow the recommended practice. It’s too easy in a standard development workflow to skip the tests. Using GitHub Actions, you can make it a requirement to have adequate test coverage and tests that pass to merge a feature branch to the main branch.
Writing tests upfront is more work, but it’s well worth it in the long run. Tests don’t need to be overly complicated. The benefit is realized because they are run in aggregate by a machine and expose any dependencies across projects. If you do not have automated testing, a human needs to be aware of all the dependencies and manually test them when any change is made. This manual approach is not reasonable or sustainable.
Putting it all together leads to the final step before merging a feature branch to the main branch. This step uses GitHub Actions and is highly configurable, but we share a proposed strategy that can be used by organizations starting their DevOps journey.
GitHub Actions allows you to automate workflows. In our case, when a developer completes a feature, they will want to merge the code to the main branch via a pull request (PR). Before allowing this, we need to:
This entire process should only take a few hours. It provides a better separation of duties so that once a developer completes their development, it is unlikely the code will come back to them for additional revisions. This updated workflow allows all team members to focus more on their core responsibility instead of wasting time in the back and forth involved with the legacy process.
We treat the main branch as production. Once code makes it to the main branch it is production-ready. A transport can be automatically created and released in the development system. Since the code has been tested in a containerized version of QA, it is safe to move directly to production.
Of course, there are exceptions, but these can be handled as such and outside the standard workflow. For example, you must coordinate the process and manually move transports if a manual process is required.
As a starting point, it’s good to handle transports manually to provide confidence that this modern process works and does not disrupt production. If appropriate, you can move to more automation after establishing a certain comfort level.
Photo by Frank McKenna on Unsplash
Photo by Roman Synkevych on Unsplash
Photo by Rock'n Roll Monkey on Unsplash
Photo by Carl Heyerdahl on Unsplash
Photo by Suzzane D. Williams on Unsplash
Originally posted on the SAP Community BlogA Practical Guide to DevOps for SAP ERP
Get the latest news, insights, and tips delivered right to your inbox.
Originally published December 17, 2021
We shared our DevOps lessons learned on the SAP Community Blog, and we hope it helps move the practice forward and gains adoption within SAP.
Modern DevOps relies on spinning up a server in minutes to run automated tests and ensure the code is safe to move to production.
Automated testing is vital for ensuring your e-commerce platform is production-ready and that customers don’t have to deal with unforeseen issues themselves.