DevOPS in SAP? My Response

This post started out as a comment to the post DevOPS in SAP? from Jakob Marius Kjær but got way too long so I decided to turn my comment into a blog of it’s own.

Jakob makes some good points and touches on things I have been thinking about for quite a while. So here is one idea – only partly formed – about addressing the ABAP DevOps issue.

As a developer I can tell you that ABAP development systems really suck! They are typically a terrible place to be developing and testing code.

ABAP development systems make collaborative development a challenge because all developers have to share the same runtime. You and I can’t really work on the same code at the same time. We can’t really work in the same area at the same time either because while I have a class opened up on the operating table for major surgery you can’t work on anything that depends on that class.

And the data in ABAP development systems rarely approximates that in the customers’ production system. Even if the development system was built using anonymised production data it doesn’t take long for developers to really mess up the data. And because it is so difficult to refresh an ABAP system the data quality degrades even further over time because no one can see the value in regular refresh of development data.

Test systems are usually better from a data perspective. Because that is where integration testing, system testing, regression testing, etc. happens so they need a much more production-like configuration and dataset. And because we developers are kept out of those test systems we don’t contribute to degradation of data quality in the same way we do in the development system.

Let us imagine what it would be like if we could provision a pretty good clone of a SAP ABAP system quickly. By quickly I mean in minutes – or at most in an hour. I have cloned one of my ABAP systems that is running on AWS by using their snapshot techniques within an hour. If I automated the whole process I suspect I could get it under 30 minutes. Advances in hypervisor, containerisation, snapshot, etc. technologies are all helping make this more achievable.

Now I hear plenty saying “But my production system is a bazillion terabytes – I could never clone that”. Sure – but what do you do now to refresh your test system? I suspect you take a subset of the production data, maybe anonymise it a bit, and use that to build up a clean test system from time to time. Maybe every couple of years? Maybe more regularly? Whatever – you have a much smaller footprint for your test system – so let’s think about how quickly we could provision a reasonable clone of that instance?

Because as a developer I would prefer a clone of the test system to the terrible development system I have now. And if I could have my own personal ABAP development system I wouldn’t have to worry about impacting other developers on my team when I break things – as I do regularly.

So we have a landscape a bit like this where individual developers – or small teams of developers – provision their own ABAP system whenever they like from a snapshot of the test system.

Now each developer – or team – can be looking at the feature they are responsible for while others can similarly work on other features. They build and test their code in the same way they do now – except they can also be confident they have a good set of test data to work with. This improves the quality of their testing and therefore the quality of their code.

If they screw up and introduce a bug in the code that trashes all that lovely clean data in their development system they can just blow it away and provision a nice fresh new system with it’s lovely clean dataset. And if they were to use a code management solution such as git they could do so without losing any of the work they had already done.

That code management solution is the next piece of the puzzle – because it has a central role in tracking each feature the developers are working on and helping them merge each feature into the master branch when development is completed.

Finally we need to deploy the new master branch to the main system landscape. If you are thinking of the traditional 3 system SAP landscape – DEV, QA & PRD – you might think that we would deploy to the DEV system. But I suggest our new development landscape has no need for a traditional DEV system – so we could just deploy directly to the test system. That is where we can run full system testing, regression testing, etc. before promoting the code to the production system.

Finally there is that little issue of configuration settings – or customisation. These need to be managed separately from the code – because after all the whole point of configuration settings is to avoid hardcoding.

Client dependent configuration could be handled in a special config client in the test system. But client independent configuration really needs to be set and tested in a separate instance before being transported through the system landscape.

Here our rapid provisioning of a development system can also be used to provision a configuration system. The only difference is that this system would need to be included in the transport landscape so that configuration changes can be transported to the test (or should it be consolidation?) system and thence through to production.

Every customer is different so these ideas might not fit all scenarios – and I know I have glossed over some complex issues in the interests of trying to provide a simple description of my thinking.

But discussions, opinions, ideas are essential if we are to help move the “special snowflake” that is ABAP closer to contemporary development practices and techniques.

Please, let’s hear yours?