Skip to Content

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?

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Nabheet Madan

    Thanks Graham Robinson for the great blog!. With the power of containerization etc. it looks to be great solution. However I can think of the following concerns might be stupid one but will be great if you can provide your inputs for the same.

    • Normally when we do our changes in D=> D screening=>Code reviews=> move to Q. In case any bug is identified in Q box we go back to D, make the change => D Screening. How will this D screening will be handled since the container is only available for the developer how will functional expert provide us the test scenario in D box? It might lead to increase in number of D->Q iteration .
    • The current example thinks about one production system, for my current client we have a complex landscape with around 30+ live production system with its own D->Q->P systems. Now in complex landscapes like these we might N number of ABAP development instances running which can make the situation complex and confusing for the developer.
    • From compliance perspective how will we handle things as normally we have the CTS created from ITSM and then changes moved via D->Q->P. If we go via this architecture once changes are done the development system will not exist any more So will it be now Quality system acting as development system from compliance perspective to track everything?
    • Lastly the most complex part which i feel is the merging of the code. This is important not only from merging point of view but also from compliance and audit.  The effort spent in maintaining the code shall be considerable?

    Thanks

    Nabheet

    (1) 
    1. Graham Robinson
      Post author

      Hi Nabheet,

      thanks for contributing to this discussion. Let me address the points you raise – but please understand that these are all ideas. It is my hope that discussion like this will flesh out more details as we move forward but I certainly do not have all the answers.

      Normally when we do our changes in D=> D screening=>Code reviews=> move to Q. In case any bug is identified in Q box we go back to D, make the change => D Screening. How will this D screening will be handled since the container is only available for the developer how will functional expert provide us the test scenario in D box? It might lead to increase in number of D->Q iteration .

      While my example did indicate that each developer could have their own ABAP instance this is not mandatory. It might sense to share an instance between several developers and of course a developer can have anyone else, e.g. Functional Export, access their current development instance at any time. The key thing is that these developer instances can be provisioned quickly by cloning the latest snapshot and then pulling down the appropriate feature branch from the code repository if required.

      I think having the developer instances having a closer resemblance to the production system will decrease the D->Q iteration rather than increase it.

      The current example thinks about one production system, for my current client we have a complex landscape with around 30+ live production system with its own D->Q->P systems. Now in complex landscapes like these we might N number of ABAP development instances running which can make the situation complex and confusing for the developer.

      Certainly the sort of scale you are talking about, 30+ production instances, and therefore I assume 30+ parallel Dev->QA->Prod landscapes with dependencies between each other, complicates the challenge significantly.

      But I don’t see how my idea necessarily would add to developer confusion – I suspect you have that issue already. 😉

      Maybe a different view is that instead of rapidly provisioning a single developer instance we need to be thinking about provisioning a complete landscape? If we assume for a moment that we can provision a single ABAP developer instance in 30 minutes, we should be able to provision a multi-system landscape in about the same time because we could provision your 30+ instances in parallel. To complete the job an automated script could “stitch together” all these independent systems into a coherent landscape but setting up trust relationships, SSO, destinations, etc.

      From compliance perspective how will we handle things as normally we have the CTS created from ITSM and then changes moved via D->Q->P. If we go via this architecture once changes are done the development system will not exist any more So will it be now Quality system acting as development system from compliance perspective to track everything?

      There is no reason you need to think about dropping your Dev system out of your landscape – I just suggested that as a possible alternative if it turns out it is not required. If you decide you need it, for example for compliance issues like you mention, then there is no reason it can’t still remain.

      Lastly the most complex part which i feel is the merging of the code. This is important not only from merging point of view but also from compliance and audit.  The effort spent in maintaining the code shall be considerable?

      Merging code is not necessarily complex. Sure it can cause some angst but the rest of the development world seems to have figured out how to manage that challenge pretty successfully.

      It is important to keep in mind that we should perform merges often and regularly pull updates into our feature branches. This helps keep all code lines closely aligned and therefore minimises merge conflicts.

      This is 100% the opposite of what we ABAPers tend to do. We typically build a new feature over many months, fill up a transport with many artifacts from all across the system, maybe fill several transports that have interdependencies, etc. Then we need additional tools and techniques just to keep track of these transports – let alone the code they represent.

      IMO We need to stop the “Big Ball Of Mud” approach.

      Cheers

      Graham Robbo

      (0) 
      1. Nabheet Madan

        Thanks Graham Robinson for the great feedback. I actually liked the suggested approach that is why thought of getting my thoughts on the same clarified. We are actually quite interest in utilizing ABAPGit, infact we have already suggested it as  one of the improvement point to our client. Important thing right now us is the architecture of how it will work. I actually liked this idea of every developer having his own environment which can be shared also(came to know from your reply).

        I do agree we ABAPer’s have to let go of our old way embrace the new ones which are far better and efficient.

        Once again thanks for the great blog and clarifications. Please keep sharing your further experience on this topic, will be helpful for all ABAPer’s out their.

        Nabheet

        (1) 
  2. Jakob Marius Kjær

    Excellent exemplified version of my ideal scenario. Maybe it isn’t as far away as I thought 😉

    Now to run devops you would need the automated testing part as well. I’ve tried today to build up a selenium script that checkout the develop branch and executes a suite of tests and upon success merges it to master. This would be possible, however I noticed that abapgit is navigated via sapevent which isn’t handled appropriately in the Web gui. So can’t figure out a way to pull the code automatically

     

    (1) 
    1. Fabian Lupa

      Possibly, I am not familiar with the “deployment options” Hyper-V provides. You could certainly copy a base image of a VM around, though that’s something you can do with every virtualization solution and Hyper-V is Windows only.

      As I understand it Docker is the go-to solution for providing developers their environment. (as long as it’s smaller than a complete ERP system)

      (1) 
  3. Matt Harding

    Note – To make things easy to follow (!), I’ve also continued the conversation back in the original blog post! https://blogs.sap.com/2018/09/06/devops-in-sap/comment-page-1/#comment-436146

    (2) 

Leave a Reply