abapGit Branching Strategy Discussion

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.