The world of SAP is changing, not only in the cloud platform, buzzwords kind of ways. But also how we perceive our beloved Netweaver stack. Not only is Abap available in the cloud now. But also opensource projects like AbapGit spearheaded by Lars Hvam is opening up the SAP world to development standards that has been available in the broader development world for years.
I’m currently working on a client, where we have integrated automated testing into our SAPUI5 builds. However one of our issues is still the backend and running the automated testing on a “unstable” baseline being the development environment.
Well with AbapGit we might have another option. Hear me out, this might be a quite radical thought for some and currently only is a theory i’ve been playing with. How can we leverage devops in our SAP ECC?
Let’s first focus on what makes this really hard?
In my opinion the issues relies in the transport management system. While it is a bulletproof way of moving development objects through the landscapes, it has it’s limitations:
- The locking of objects for multiple developers to change the same object
- Frequent releases of transports could potentially become unmanageable for the basis team depending on their release strategy and what tools they have available
- No way of merging multiple streams (Project stream and BAU) without having to do it manually
There might be more and some of my arguments above could probably be proven wrong in some cases.
If we look outside of the SAPosphere we see subjects around containers, Kubernetes, CI/CD practices etc. Well could they be leveraged with SAP ECC.
In the perfect world every developer would have their own SAP system on their local machine to develop on, then use GIT to merge the code and the GIT repo would execute a pipeline that would spin up a docker container that would execute your automated test scripts and if everything ran successfully deploy straight to production. WELCOME DEVOPS and Amazon release new code every 11 seconds like conditions!
But let’s be honest, that is probably pretty far off. A lot of SAP customers would still want some sort of manual testing to occur and the developers would never be able to have their own SAP system (Maybe Abap on SCP could help in the long run?)
Well at my client we are discussing concepts around how to at least leverage some of the benefits of devops and CI/CD. This is my theory and I would love your feedback.
Step 1. Disconnect the development environment from the transport path
Step 2. All development is still happening on the development system. The code is continuously pushed onto a feature branch in GIT. Automated testing scripts is build to handle all new development
Step 3. When the code is ready for testing a merge request is created in GIT
Step 4. A second developer reviews the code and finally accepts the merge request onto the develop branch
Step 5. A pipeline is triggered which automatically pushes the code to the testing system and executes a suite of automated test scripts.
Step 6. Everything passes and the new code is pushed to the master branch and sits in a transport ready in the test system to be moved to production OR the automated testing fails and the code is reverted back to the current master branch and the developer has to fix the issues for a second attempt.
What would be the benefits of the above?
Well first of all we would have production ready code sitting ready for launch in the testing system at all times. Also expanding and building automated testing scenarios for all development and my argument would be that within a period of time you would have thousands of test scripts that essentially could act as a regression test for your upgrades etc as well.
Think of an SAP upgrade that could happen close to overnight because the vast majority of the testing effort was handled automatically.
There is multiple ways of doing the automated testing. Currently there is a fair bit of buzz around the unit tests in Abap as well as Opa5 or Qunit in SAPUI5. However this can handle the lowest part of the testing pyramid.
Personally I see at least as much value and maybe even more in Selenium testing, these can be developed in Java or Python and are fairly simple to develop. All testing on SAPGUI can be handled via the webgui and your WDA and SAPUI5 is working on the web already.
All i’m saying is that we can do what I proposed today. However it would require a significant shift in mentality in regards to development, testing and collaboration in the SAP ecosystem.
What is your thought?