Skip to Content

Good day follow ABAP citizens and especially those of you using abapGit.

My team and I are reaching out to you to discuss some development questions which popped up after introducing abapGit in our company, which creates SAP 3rd party software, consisting mainly of ABAP and UI5 code.
This article deals exclusively with the ABAP side.

First of all we love abapGit, and we believe many do…

GitHub repository

Our git repository is hosted onsite and has been made user friendly with GitLab.

We push at least once a day our commits, which gives us code versioning (an extra layer of backup so to say).

It also makes code reviewing a lot easier by using GitLabs code review functionality.

We recently reviewed the possibilities to use branching, and came to the conclusion that we cannot use that with our current infrastructure.

The remainder of this blog looks into how branching could be achieved with abapGit.

 

Scenario 1: Without Branching

That’s how we currently run things. All the developers working on the same SAP system with the same code base, everyone pushing to the master “branch”.

Pro

  • better code versioning
  • easier code review

Con

  • Branching not possible, developers change objects in the same code base at the same time
    • Switching to a branch, will change the code base for every developer, though they think they still might be in their branch.
  • Commits can be flawed through other developers
    • Dev 1 changes Object A, so does Dev 2 afterwards.
      Dev 1 commits without knowing about the changes Dev 2 caused on Object A.
    • Yes, the person who made the last change gets displayed on the staging screen in abapGit, but you still might fail to see that.

 

Scenario 2: With Branching

The root cause for not being able to use branching right away, is that, all the developers using the same live code base.
The developers aren’t shielded by code changes their follow comrades perform.

So the first strep to do real branching must be separate development environments for each developer. That means, each developer gets his own SAP system to develop in.

The brings us to the first overall minus:

  • Higher maintenance cost, as the number of SAP systems rise by the number of developers

 

Local VMs

Our first thought was, why not run the SAP systems virtualized on the developers machine.

The developers, while being on a task, can push into their branches, until they create a merge request.

The main development system (DEV) only pulls from the master branch, which only contains approved merge requests.

Pro

  • no network interference when being connected to your SAP system
  • you could work without being connected to the company network
    • you only need this when you push to the git repository
  • running on an SSD the SAP systems can be blazing fast

Con

  • Higher maintenance cost
    • Admins don’t have a hold on the machines easily
  • Developers need to know how to start/stop the VM/SAP system
    • maybe even backup the VMs from time to time themselfs

 

Then several overall problems stroke us:

Updating the developers SAP systems

  • How does your machine get patches (Support packages, notes, OS level patches, …)?
  • How do you get customizing, master and transaction data which one might need for developing a feature or to replicate a bug and create a bugfix?

Update the main development SAP system

  • How do you deal with development objects, which abapGit cannot serialize?
  • How does your master development system receive customizing, master and/or transaction data which is necessary for your new feature?
  • How do you handle development objects being assigned to the right transports on your main development system after a pull from the master branch?
    • You might have a sophisticated transport convention to facilitate code reuse. We do.

 

Somehow you need a strategy for these problems:

  • Individual maintenance and configuration and individual importing of customizing and workbench transports for unserializable objects
    • Sounds like a mess
  • Client copies of the main development system (SAP only)
    • Just gives you customizing data
  • Cloning the VM on which main development machine runs (OS+SAP)
    • And renaming the SID and Full Qualified Domain Name, cause otherwise you run into network problems

 

And how often do you allow those updates?

  • On demand
  • Before you create a new branch
  • When a new release cycle starts

 

Hosted VMs

Cause getting updates seems to be a big issue, maybe it’s better to have the VMs hosted, instead of having local VMs.
So updates, with whatever strategy, can be performed more hassle free.

Pro

  • Admins have access to the machines at any time

Con

  • Hosting costs for running the developer VMs

 

Bottom line

So, what are the advantages of going through all this?

From our point of view:

  • True branching gets possible, no interference from other developers during coding
  • Even better code review due to merge requests combining multiple commits
  • Better support for different release versions, easy switching to a release branch.

 

Is it worth the effort?

Our team doesn’t know. The overhead of keeping the systems in sync, seems to be huge.

At this point we don’t feel comfortable and rather turn to you the community to hear your opinion and experiences with this topic.

 

Thanks a lot,
André

To report this post you need to login first.

22 Comments

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

  1. David Henn

    Very nice idea,

    we often joke about “each developer should have his own system”.

     

    The update problem might be serious.

    I don’t think, all dev systems must look exactly the same (customizing and application data wise). You have to deal with all different types of configuration at your customers anyways.

     

    Cheers David

    (2) 
  2. Former Member

    Great points. Git is awesome, but isn’t really that compatible with the remote codebase. Alternatively, SAP could develop server-side object swapping based on what branch you’re on, but that would certainly not be a quick job.

    (1) 
  3. Former Member

    Great post and congratulations on your development environment. It’s already 100 steps ahead of the normal ABAP development strategy!

    I am trying to start using abapGit in my company but the adoption from other developers is not easy.

    Last year I attended the session of abapGit at TechEd by Lars Hvam where someone from the audience who worked at SAP told us that SAP is working on some project to deliver Git in SAP environment.

    It’s now almost one year after and still nothing on the topic except the excellent work that Lars and the contributors are doing on abapGit.

     

    (3) 
  4. Florian Henninger

    There are a lot different points you have mentioned and I’m also joking that everybody need an own ABAP-Stack for branching..

    Let’s see what the Teched-Session now brings up to light and right now that is the best place to ask.

    I have it on my list for BCN. So if there is no answer till that point I try to do my best to give you one.

    ~Florian

    (1) 
  5. Alexander Tsybulsky

    Awesome article and analysis ! Thanks ! Interesting idea with centralaized managed dev envs.

    Just wondering if it is theoretically possible to solve it on DB level. Some kind of virtual DB instances which refer readonly common part with customzing and standard objects, and separate Z objects with some kind of sharding … (I hope it is not complete non-sense I’m saying 🙂 ). This would potentially reduce costs a lot.

    (1) 
  6. Uwe Fetzer

    Good points. Inside the SAP Mentors program we are discussing this issue since years.

    In my opinion we don’t need separate systems but “just” separate virtual runtimes inside the SAP kernel. Every source you change should run in your own runtime. Everey unchanged source “lives” in a global environment.

    (2) 
  7. Enno Wulff

    In my Opinion ABAPGIT is great tool that revolutionized the way ABAPers think about their sources and that makes collaboration on different SAP-Systems possible.

    But I do not see the advantage of using ABAPGIT for a company. If it’s “only” because of the poor versioning of ABAP-sources there should be another way to make this better. Using ABAPGIT (for local custom code development) makes things more complicated than easier IMHO.

    I will be glad if you can tell me the reasons for you using ABAPGIT in your company!

     

    The most annoying thing about the versioning “tool” 🙂 in ABAP is that the versions are hidden behind the specific technical repository parts. For example: Each method gets versioned on its own. You cannot open the class and look what changes have been made.

    And that’s the point where there should be a tool that gathers all dependend parts (methods, test units, includes, dynpros, rollnames, …) of an object (class, program, database table, etc.) and shows an overview of all changes made:

    • View 1: arranged by the parts of an object
    • View 2: arranged by last changed date
    • View 3: arranged by last changed user

    All integrated of course in a global view for packages  or last changes since.

    (0) 
    1. André Schaarschmidt Post author

      I am right now doing code review of company ABAP code of my colleagues with gitLab, cause we use abapGit:

      Try that without abapGit.

       

      To your other statement:

      It’s even not enough to see all the changes to a class, or to a package.

      What you really wanna know is, how did my code base looked at a certain point of time spread over all relevant packages.

       

      abapGit is helping you with that.

      (3) 
      1. Enno Wulff

        ok. that is a good point! 😉

        Do you “only” research the code of a date in the past or do you completely pull all code active at this point to see how the system behaves?

        But: Code comparison also is quite good in ABAP, isn’t it?

         

        In SNOTE there it’s a bit different:

         

        So the “complicated” tools for comparing sources are mainly there in the SAP.

        ABAPgit and gitLab seems to be a powerful combination!

        (0) 
        1. André Schaarschmidt Post author

          Sorry, my screenshot didn’t really show the power of using different code review tools compared to the one inside SAP, which was a good point on your end.

          The real strength is to have discussions inside the code review tool about certain sections of your coding:

           

          I am not sure I correctly understand your question:

          Do you “only” research the code of a date in the past or do you completely pull all code active at this point to see how the system behaves?

          Can you please try to elaborate on your question a bit more.

          (1) 
          1. Enno Wulff

            Discussing the code is a nice option! thanks for providing a bigger picture – in the true sense of the word… 😉

             

            Do you “only” research the code of a date in the past or do you completely pull all code active at this point to see how the system behaves?

            With ABAPgit you can push new code and also pull older versions. My question is, if you just look at the code at a defined date or do you reactivate all version by this date?

             

            (0) 
      1. Enno Wulff

        Hi Suhas, you wrote:

        I really like the branching functionality which lets the developers to work on parallel releases without the complex mutli system landscape.

        How does this work? How can you have different versions parallel on your SAP system with ABAPgit??

        (0) 
        1. Suhas Saha

          Hi Enno,

          How can you have different versions parallel on your SAP system with ABAPgit??

          “Branching” is a Git concept which has been implemented in abapGit as well.

          From a high level i can say that abapGit parses the “supported” development object into XML files and the respective Git-Repository [in my case abapGitServer(aGS)] manages these files. The parallel versions don’t reside on your SAP system per se, well in case of aGS they do!

          For details about the architecture & implementation you have to contact Lars Hvam

          The only missing piece of the jigsaw is the “merge” functionality, which has not yet been fully implemented. So, like me, if someone is using abapGit with aGS, then (s)he cannot merge the branches. This for me is a deal breaker 🙁

          BR,

          Suhas

          (1) 
          1. Enno Wulff

            Hi Suhas,

            Yes, I know branching. But that’s the point: in non-SAP (“normal” :] ) programming languages you have different directories for different branches. Whatever version you like to compile: you refer to the files in this directory.

            In ABAP you need to have the sources stored in the SAP database. And there you can only have one version at a time. So developers can only work on the one version that exists in the SAP system.

            Parallel development is not possible. Even if abapGit is used.

            Cheers Enno

            (1) 
            1. Suhas Saha

              In ABAP you need to have the sources stored in the SAP database. And there you can only have one version at a time.

              Now i get what you mean.

              But you can switch the branches right.

              Suppose i’m working on a Release and i have a production ticket to solve. I switch to the “master” branch do the fix, test & transport. Once done i can switch back to “Release” branch. Knowing all the time that the production-fix didn’t contain any untested “release” code. That’s what i meant by parallel development.

              Of course there are many factors like transport-lock, object-lock which do not allow typical parallel development in SAP.

              Sorry for the confusion!

              BR Suhas

              (1) 
              1. Enno Wulff

                Thanks for clarifying, Suhas!

                In this case you must make sure that no one else is programming!

                It’s a nice option but exactly the opposite of “parallel development”… 🙂

                Thanks for showing: This might be an option for the problem of one of my customers…!

                (1) 
                1. Suhas Saha

                  This might be an option for the problem of one of my customers…!

                  Unless your client is open to using external Git Repo, i wouldn’t recommend using branching.

                  It’s a nice option but exactly the opposite of “parallel development”

                  True that. In my company “parallele Entwicklung” means working on releases & production tickets at the same time 😛 Let’s put it as lost in translation 😉

                  (1) 
          2. Lars Hvam

            hope to implement it some day :o) most likely in abapGitServer, as it would be nice to also support pull request functionallity, and the web gives more freedom when designing the UI

             

            (0) 

Leave a Reply