Technical Articles
Brainstorming on abapGIT
So I finally got abapGIT running and connected it to GITLAB. I can commit, pull, branch, revert … how nice is that?
Now comes the harder part: How do I set up GIT usage in my developer team? Actually, I am in a brainstorming mood, and I’d like to share my thoughts so hopefully some inspiring comments will come along….
Having read this very nice blog post I understood that there will be no way to work with multiple branches in a centralized code base.
Now what do I want to obtain from my GIT-powered development?
- fearless refactoring – always being able to revert to my starting point when I got stuck
- easy code review – see all changes at a glance, add comments, discuss the code (GITLAB) can do this
- easy transport of reusable code between different abap-based systems (ERP, APO, GTS, …)
We have a 3-headed ABAP DEV team and practically everyone is intended to maintain everything. So having two ABAPers working on the same development package happens all the time. In the past, one began to change code and then stumbled across a class method that is blocked by the colleague. Here the hassle begins: Can we merge the two change requests? Have you already finished? and so on….
With GIT, one could first check the GIT repo for the development class. If the colleague did right, there should be some commits since the last “go live” commit. It now should be easier to understand, what’s going on.
This means, commits should be done frequently…. at least once a day? After each successful test run? still thinking…
I also thought to keep ongoing development in a branch – the colleague is immediately aware of the WIP state of the dev package. Each go-live should then imply a merge with the master branch.
I still am not sure how to organize how two developers could work simultaneously on (different) objects of the same dev class. abapGIT will keep always the whole package in one repo, so how divide things? There are really huge packages we created in the past. Maybe it would be a good idea to first split the packages in smaller sub-packages and create the git repos for those.
That’s it for today. Looking forward to read your thoughts!
Maybe I can answer a few questions. Our team has 5 developers working on the same package, as well as a few others we maintain but not that often. We are trying to use abapgit to improve the transparency of changes to our packages.
I think if there's only 3 of you, you will have an easier time coordinating.
Note that what we do are not necessarily best practices, they are a compromise between doing it right and avoiding too much overhead. I also don't want to order people to do things. The only necessary element is to commit your work when it is finished so that your changes don't show up for others forever.
Currently:
abapGIT will keep always the whole package in one repo, so how divide things
Abapgit treats subpackages as folders in the repo. If you can affort to reorganize your objects, you should. However, if you have related packages which are not children of the versioned package, there is no way to iclude them in your repo.
Abapgit is usually smart enough to know who did what and allows you to filter out the changes.
A very nice feature Patch, which allows you to pick and choose individual lines to commit, so you can find your changes even if your colleague changed the same class.
We also have commits posted to a slack channel which is configured for every repository we maintain. There you can view all commits from all repositories linearly.
Note: we don't use branches as they don't work properly anyway and confuse people. Commits go straight to master. The history is still much better than what you get from the transport management system.
The only use for a branch is to create it right before a commit to trigger a pull request for review. In practice, our developers don't want to do code reviews with pull requests, mostly because they don't find the UI easy enough to swallow and would rather look at the objects directly in the IDE. This might improve in the future as the tooling around abap improves.
We link commits to JIRA tasks, so we can find related commits linked to the same task. And the other way around, any commit should have a task number attached so you know where it belongs.
I often pick interesting commits from the slack channel and do a short review, sending the comments to my colleagues directly. It aslo improves my own overview of what is going on in the codebase.
Also note that the JIRA/Slack integraiton was very easy to set up.
I am mostly afraid of doing pull/reset when other work is uncommitted as I don't want to mess it up. Do not combine pushing and pulling at once. Pull only if there are no uncommitted changes on the system and reset if it's only your changes.
Some things may be easier to do on serialized code, for example do a large find-replace in your editor of choice or move a bunch of objects at once. Make your changes locally, review, commit and pull to the system.
You can treat your local objects as your personal single-dev system, version your local packages and experiment with those all you like. I do this to have more freedom when prototyping.
We still use transports and UDO in the end, although we don't have much freedom in this. Abapgit is currently for tracking development work only.
Actually, reading through this again I feel like we're not doing anything properly and it still improves the development experience in our team. It can only get better, you should give it a try.
Cheers,
Frederik
Thanks for replying! One thing is not very clear to me:
If you fork a branch right before a commit, how will you see all the changes in your merge request?. As far as I understood, the code reviewing process should be set up like this:
We don't branch because branches are not real in this kind of workflow. You see other people's changes in your branch and by switching branches, you switch branches for everybody else.
So we go with the path of least resistance and just don't branch at all. You can collect your changes in a branch by switching to it right before a commit and then submitting a PR, but like I said above, people on my team won't use it and it will only serve to confuse them.
Although I would say that with only 3 developers who agree on the process, it is manageable.
After reviewing, merge the branch into master and do the go-live
For now, we don't "go live" from our repo. It's only really there to keep track of changes because transports are terrible for this. For delivery, we use the classic transport management in the end.
From my point of view, abapGit does not (yet or never) replace the ABAP transport process so I treat it as productivity tool for developer to get benefits that you mentioned in some scenarios. But we still need to follow ABAP way of work and its constraints such as only one developer can work on object or we should only assign a change to only one transport.
My use of abapGit would focus on new object development where split things into smaller packages. Each package provide single purpose (SRP). When making changes in different package, create different transport for different packages. I try to avoid branching because we cannot simulate the same behavior in ABAP. The only times I create branches are when I want to submit MR/PR to get my remote peer to review my code.
For big existing package, I rather go with the old way without abapGit.
abapGit was never meant to replace the transports and it never claimed to do so or plan to do so. I'm surprised it's not prominently noted in the description on Github but every session about abapGit always starts with a disclaimer that it's not a replacement for STMS.
Maybe you got me wrong. I do not think of transporting repo objects with abapGit. I only want to use it for coding review purposes. The workflow with SE80 would be:
Since this is very complicated, I thought of using a merge request in GITLAB, where I can see all changes at once.
Personally, I'd recommend using sub-packages regardless of abapGit, they're very helpful. Regarding your other questions I bet Graham Robinson and Lars Hvam would want to chime in.
Thanks for the mention Jelena.
Most of the answers to Jorg's questions probably all start with "It depends.....". 😉
However quickly reading through this discussion there are a few observations I would make about how I use abapGit for ABAP development.
Firstly, I commit early and often. Much more often that once a day - more like several times per hour. Why? Because I can revert to any of those commit points when ever I need to. I make mistakes - all the time. I need to be able to revert to previous working code - all the time. There are other reasons too.
Secondly, I use branching all the time. I also secure my master branch so that I can't accidentally commit directly to it. There are lots of reasons for doing this but for me the biggie is that I can revert to the original code quickly just by switching back to the master branch. And when I do this I do not lose any changes as they are still in the feature branch.
I might do this because I am in the middle of working on a new feature when an emergency change has to be implemented. I can switch back to the master branch, apply the fix, release the transport containing the fix, then switch back to my feature branch and continue working from where I left off - not forgetting to pull in the emergency fix of course.
I also do this because as I am working on a new feature I might try several different ways of implementing it before I decide the best way. So I can create a branch for each concept then delete the ones I don't want to stick with.
And finally there is no doubt in my mind that smaller focused packages are more manageable than those huge big balls of mud we inherited from R/3 2.0.
Cheers
Graham Robbo
Hi Jörg,
currently I have pretty the same question on my todo list.
I really like to use abapGit and I see some advantages but how to integrate this tool in the current processes is a challenge.
Using the merge request for code review and dealing with feature and release branches would be nice.
The next step for me is to think about the integration to the current toolset and change process.
Regards Wolfgang
We are struggling with versioning and pull requests (like everyone else I guess), the process we've found to be working for us is
This allows us to get a nice version history and a nice UI for code review. what it does not help us with is to retrieve an old version of the code. We have a strict "no-pulls"-policy back to SAP, since we have branches in GIT and not in SAP it could be messy.
To handle dependencies and locking objects we try to follow the first point of the agile principles, "People and Interaction over Processes and Tools". Basically if you find yourself working on the same object as another developer, you are supposed to go over to him and finish his story before continuing on your, not put your objects in the other developers transport and create unnecessary dependencies between user stories.
We also strictly release code to test and production, the import queue to test must be empty at all times, the import queue to production should be empty, but there we might have dependencies to external systems that stops us. The goal is that we always are ready to go live.
The biggest challenge we have, besides the no-branch-problem, is that we have one big repo with all our z-objects, and the performances of abap git on bit repos is not the best. I would like to split it into smaller repos but that would require alot of code refactoring.
This is going to be a blog post!
Some time has passed and meanwhile we have set up a procedure almost identical to the one you described here! I am pleased to see that others came to the same conclusion. Thanks for sharing!
I'm not so quick 🙂
I think this is an approach that works "ok" for a small dev team (we're 5 developers), but it won't scale to a big organisation.