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.

9 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. Guyon Cumby

    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. Sergio Fraga

    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) 

Leave a Reply