DevOPS in SAP?
Hello everyone.
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?
This is amazing. It's good to see that automation has taken over the Mobility and made the development process so streamlining.
Hi Rakshit Soral
This is still only a concept. I'm hoping to spark a debate on how this could be achieved.
One problem would be all customizing transports.
I needed a bigger area for my comment. https://blogs.sap.com/2018/09/07/devops-in-sap-my-response/
I'm totally with Graham on this one.
I really think that personal dev sytems are a precondition for dev-ops
In your scenario every commit is based on the current dev system, which is a patchwork of master, unmerged branches, uncommitted changes.
Over the time will sway further and further from master and you will start dragging (or depending on) bits of unrelated developments around. Yes, if all of this is covered by automated tests and you run those after consolidation too is not the end of the world, but it's a tall order.
And the simple idea of having my dev box out of sync with my git repo is painful to me
Hi Jakob & Robbo,
I figured I'd sum up some of my thoughts from the Twitter conversations as I've been looking into this also (alongside TDD and other test frameworks which is another story)...but still have so many thoughts.
But let's start with a few unorganised thoughts to start with.
Some guidlines to consider:
a) It has to be easy to pickup for most developers (there are hopeless cases out there which would leave me stumped on what to say)
b) Focus on a solution that doesn't cost the earth so you can sell it to the CIO
c) Handle Customisation/Configuration which could be client independent
d) Focus on R/3 or S/4HANA today (as once you move to S/4HANA Cloud - ABAP development falls into the bucket of any other cloud development which means we are dealing with much smaller footprints and little to no config so lots of developer copies are with the one git repository is an easy option)
e) We should look at 2 scenarios. BAU change and Big Projects
f) We'll focus on single, non-integrated development as if we throw in SRM, GRC, etc; then we have no hope...
g) I suspect functional consultants will still prefer to stick in the one system for config - so do we accept that as an assumption?
Down to the brain dump:
So I really liked breaking the assumption of needing transports on in Dev; but the client-independent transports are the killer for that one. I mean, we could have a config only client, and use SCC1 to copy to the non-transport client but without solving all config, I think that is a showstopper. A completely separate config could work, but how you align the changes to branches is unrealistic to consider solutions for.
Robbo's last picture is really close to ideal, but the scaling of this will be a challenge if you have too many "tracks of development & developers".
That said, I can't think of any other solution so it comes down to how do you support this scenario.
But before we go there, let's throw in the requirement of S/4HANA which means all developers need a potentially sizeable HANA instance...This really will probably throw AWS or similar cloud instances out (at least from selling the what could be >$5000 per month developer instances cost to the CIO)
So let's think about alternatives for a second - obviously we can't all have 1TB HANA instances; so if your production system falls into that category as a business - then you're going to have to spend money on figuring out how to create dev instances that fit onto a 32-64 Gig instance (leaving enough headroom for you to run your office Windows/Mac environment.
So assuming < 32G dev instances can be easily replicated, why not give all your developers a 32 or 64gb i7 developer machine, that you can run a s4/HANA instance on. This will make the developer truly portable and able to work offline, not to mention, giving them the power they need to develop as fast as possible!
Unfortunately, that also means your average ABAP'er will not only need to learn the ins and outs of git (there's a good open.sap course for this), but learn a lot more basis and virtualisation.
Plus the whole, we'll need the ability to keep a master "Dev Server" instance.
And if you bring in a developer for a week - do we just let them log into a developer's instance.
Then there is the fact you'll need to somehow work out how config makes it to each developer's Dev Server (e.g. Transport path after production, plus SCC1 target from the assembly/config master)? That said, if we've moved a config transport to Test, we should follow the same approach as we do with development and merge that with our branch almost immediately so we can pick up new bugs.
Now - if you consider where you are today without any of this, and how to get management to help set this all up...Well that's going to be a challenge (I had trouble convincing people that developers should have more than 8G of ram)! Hopefully leadership is fully onboard, maybe you are starting a new S4/HANA implementation, or maybe you are in support with only a couple of developers with the possibility of doing this...
Finally, how do you get everyone up to speed on this without making this one massive project.
I'll end there, but that's my current brain dump for further discussion (most likely at TechEd in Vegas)!
Cheers,
Matt
Nice that the discussion around DevOps and the adoption of its practices and methods in ABAP is not quieting down! 🙂
I am on the road at the moment, so I just want to point you to the video of my SIT Berlin Session from last weekend: DevOps in SAP ABAP Landscapes - https://youtu.be/isy6CMHHM4I.
It contains a very brief summary of the results of the DSAG DevOps meetups since last August.
We are also preparing a blog post with more details, but it is not yet finished. But safe to say it will go in the same direction as this discussion 🙂
A few years late but this is how we implemented DevOps in SAP. https://blogs.sap.com/2021/12/13/a-practical-guide-to-devops-for-sap-erp/