Skip to Content
Technical Articles

The journey to Git-based ABAP development: Part 3

The main reason why we are starting Git-based development at Basis Technologies right now is that we are about to embark on a long-lived project that will touch a lot of our codebase, and we can’t stop the world until that’s done. We anticipate hundreds of conflicting “files” (out of about 10k) and we’re expecting that Git will make this a manageable process, albeit not painless.

 

The key is: we want to clean up our codebase as much as possible before we start.

The plan

“No battle plan ever survives contact with the enemy”

Will likely change as we go, but for now roughly looks like this:

 

  • Clean-up the codebase:
    • Complete as much WIP as possible
    • Consolidate our codebase – we want to start as close as possible to production, but including a number of beta and unreleased additions
    • Standardise the code formatting
    • Align the main dev system with the resulting code
  • Start developing two branches independently:
    • 1. The long-lasting project using abapGit
    • 2. All the rest with a traditional TMS workflow, but committing every change to Git once it gets past QA
  • Merge the two
  • Run an extensive regression test

Code formatting

I’m a big fan of Pretty Print, almost always run it before saving. I find it tedious to manage indentation and capitalization manually. And when everybody uses the same settings it allows more uniformity in the code and smaller diffs. Sadly it’s not our starting point.

 

When formatting is uniform, a small change will look like this:

When it’s not it will look like this:

The sample pictures are JavaScript files, but apply as well to ABAP. Yes, in SAP GUI we can ignore case and spaces, but in our scenario merge will happen and most merging tools don’t understand ABAP syntax. While it might be possible to work around it I think standardising the code formatting is a good idea regardless.

 

I wrote a small command line utility to automate this task.

TMS and Git integration

We plan to track in Git all development done, both with and without TMS. Changes done in the main dev system will go to a branch only used to keep track of changes made there, tested or not. This will only be used for auditing purposes.

 

Changes who make it to pre-production will be tracked on the master branch. We will use the ABAP Get background feature, and will probably create our own background mode to allow cross referencing commits with our issue tracking software (Jira).

 

For the Git-managed project branch, every developer will have its own repository and send pull requests to the central one

Merges will happen on user laptops and get on the main repo via pull requests until the end of the project. Then a transport with the delta between the merged project branch and the master branch will be generated and fed to the main dev.

 

Any conflict with changes imported in pre-prod will be ignored, as they’re already in master. For the others we don’t have a solution yet.

Merging strategy

The most obvious options are:

 

Merge once the project is completed. This has one big advantage:

  • Merging is an expensive operation, and this allows you to only do it once

 

…and quite a few disadvantages:

  • Will be a big, complex job difficult to split between developers
  • Whatever goes wrong we will only know at the end of the project
  • Not very agile or DevOps

Our favourite option is to merge small chunks frequently.

This way we will probably end up merging the same bit of code multiple times, but has lots of advantages:

 

  • Individual merges are small, a single developer can handle it without a sweat
  • If the workflow is problematic we will know it immediately
  • It’s agile and DevOps


Please note that all merges but the last go from the master branch to the project one, and the last goes the other way around

Ideally one would like to avoid long lived branches altogether, but here is not an option. Keeping the project one in sync with main will mitigate the disruption caused by the final merge.

Conclusions

Some preparatory actions have already started, but most of the real work will begin in June. We will probably make some adjustments along the way, and I definitely plan to try this approach on a smaller scale before committing to it. 

 

But that’s the plan for now. If things go well we might even end up making some version of this part of our regular process. Or perhaps we’ll regret we ever tried. I guess only time will tell.

Previous episodes: part 1 and part 2

6 Comments
You must be Logged on to comment or reply to a post.
  • Sound like a long path 🙂

    One question regarding your merging strategy:

    How are you going to track down and solve conflicts in dependent non-code objects (e.g. a change in a referenced DB table, dynpro, etc.)?

    • Good question, but I don’t have a clear answer, which is the main reason why I want to do it often and in small batches: if something will go wrong I’d rather know it before we invested months of development.

      We did run a handful of test merges already with smaller issues just to get a feel, and worked relatively smoothly

      • Anyway, DDIC and dynpros are covered by abapgit
      • Merging offline you risk to break stuff, which yo can mitigate with offline tools like abaplint. And then activate and test in an ABAP system before you put through the release path.
      • Customizing is more of a problem, but luckily we do very little of it and can handle it manually. Or perhaps by doing it all in the maintenance path/branch which still mostly runs on transports
      • For most cases defining project boundaries is also a challenge. We are delivering a product, so it’s not an issue for us

      Bottom line,this series is about our plans and experiences, I don’t think this is anywhere close to be mature enough to have well defined best practices

      • Thanks again for sharing your insights.

        I’m aware of the fact that DDIC and dynpros are covered by ABAPgit.

        The reason I asked it is that I’m not sure how simple is to cover changes on dependent objects.

        e.g. changing a DB field which has no conflict with other version, but it may break a related ABAP code in other version.

        I wondered if you have any trick up your sleeve 🙂

        I guess that manual activation of objects with some trial and error is still in inevitable.

        • That happens with code to:  a = a +1. and a = 1 +a.  in different lines will both make it to the merged code fine, but break the functionality

          And the only real solution is having extensive automated unit and integration tests to run after the merge.

          Sadly I only have the former at the time, and with low coverage, so we’ll resort to smoke tests for the routine merges and a full regression test at the end.

          Running tests is trivial, writing them is the hard part