ABAP Code Reviews with abapGit
People think there isn’t a code review tool for ABAP. It turns out you can do that with abapGit.
abapGit is an open-source git client for ABAP. It serializes source code and data dictionary elements to plain text, so that they can be persisted in a git repository.
An example of a serialized class
With this serialized code you can leverage Git services, such as GitHub or GitLab, to create Pull Requests. Think of a Pull Request like an SAP note, where you can see the code differences and the reason for the change.
Then, with GitHub, you can create code reviews for it, like on the image below:
A pull request review in an abapGit repository
Although abapGit connects to an online repository, in our approach we use another functionality: you can export all serialized code to a zip file (or even export a transport request contents). We use that to manually commit the differences.
The programmer has in its computer a folder with the serialized code. Then, she manually commits the change and pushes to the online repository. We do because using branches at ABAP would be confusing, since this concept does not exist.
Next you will find a detailed story on how we, at IBSO Engineering Latin America, do this.
Eliza is finishing the development of a user story in this sprint. One of her team’s definition of done rules is to have a code review. This code change is not so big: some new code in a class along with its unit tests. She also did a refactoring on some parts.
She starts the GitHub Flow. She goes to the cloned repository in her PC, and runs a git pull to get the latest version from the repository. Next, she exports all project contents to a zip file. She creates a new branch and extract the files which she made the changes. She commits the changes, and push to the online GitHub project repository.
There, she opens a Pull Request and assign Daniel to review her code, which he starts right away.
The first thing Daniel notices is the Jenkins build is failing. Every new pull requests triggers an automatic job with the new source code. This time, there are abaplint warnings she should fix. Also, Daniel points out that there is a missing unit test and, in some points, the coding conventions were not followed. Daniel marks the review as “Request changes”.
Eliza fixes the code review findings, and submit a new version. If Daniel had not marked “request changes”, she would not need to do this. Daniel reviews the code again, and approves the Pull Request.
Just try it
This practice require little effort to put in place and generates a great return. You will bring the benefits of code review to your team: knowledge sharing (both technical and functional) and code quality (make it easier to introduce new features and fix bugs). I suggest you try it and see the effects for yourself. If you have any question, leave a comment!
Good blog content, Eduardo Copat .
About the review process, how are the review comments informed back to Eliza?
She will receive an e-mail, because someone has commented on her Pull Request
This is a great idea!!! I hated having to do the code review and either - put comments in the code or print the code and mark it up.
Easier if you are not all in one location too!
Hi Eduardo, nice blog.
What exactly do you build in Jenkins?
For the particular example in the story, we have a job that is executed for every new Pull Request - it runs abaplint on the Pull Request code. That is the Jenkins Build I refer to.
However, just out of curiosity, we also have other periodically jobs:
Nice blog post Eduardo, thank you very much.
This approach works nicely when the changes you are making are clustered around only a few packages. Has anyone experience if this also works for a huge amount of sources spreaded in many packages? Then also the git repository needs to be shared across team boundaries.
Yes, git repository needs to be shared across team boundaries if you have interdependencies. If dependencies flows only in one direction (they should) then you probably can keep you "core" sources in its own package and use git submodules to "update" your dependent software (you probably won't have non-core developers changing core source).
Other cases can be easily handled within the same git repository.
I'm seeing this working well on a 30-ish developers working within the same module. Just have to take care to keep your requests/tasks small so only upload the small incremental changes for review. (ps. we did a small tweak on abapgit to download files on a task level)
Thank you for sharing your experience Eduardo.
We are looking for a better way to perform ABAP code reviews in our team. We used to have transaction CI_OVERVIEW, but got deprecated for some reason(s). We also looked at this previous blog post on ABAT Git.
From your experience, what is:
1- the learning curve for people to adopt this way of doing code reviews?
2- The effort associated to push code for review? (export, commit, push, ...)
3- How can we push for a code review out of a transport request?
4- Any experience with conflicting changes (2 developer who want to modify the same piece of code before the code review happens. How does this process deal with this code lock?
I would like to be convinced that it overall brings us more value than overhead to use ABAP Git.
Currently we provide code review items mainly via emails where we can add screenshots if needed. Not as good as Git could offer, but overall working. If, with minimum ramp up, we could use Git, I would clearly go back to my team and test it.
1 - It is quick to learn. If you have anyone with git experience, it is even quicker.
2 - It takes a few minutes, but it is worth the effort.
3 - abapGit has an option to export the transport request contents to zip.
4 - Yes, it has happened. In that case, the developer has to manually changes the lines added/removed on the file. It is more overwork, indeed.
Another option is to create a single code review for both (in theory, if they are touching the same object they are changing a similar feature).
On your quote:
I suggest you go ahead and try it for a few weeks (if project is agile, it could be your iteration duration). Talk to your team and say it is a trial. Then, discuss the advantages/disadvantages.
We found it much better than CI_OVERVIEW.
Maybe I’m missing something here, but what prevents anyone from making changes in the code base, which lives in the ABAP repository, and not committing anything to git?
I don’t see any option for branching either, in my company there is only one development system, there’s no way of having multiple active versions of the same object.
Nothing… you will need to count on ethics and professionalism.
With a solo shared development server, nothing. With at least two servers, you can code in a pre-development server, commit via abapGit directly to GitHub and give the permission to pull the merged changes to the development server to someone reliable - definitely not you 😀
It is trivial to spin up a new server with NW in Docker:
I am not familiar with GIT. But my main question how is it a better review than doing it in SE80 ?
How were you doing reviews using SE80?
I suggest you try using the approach I mentioned and check if it is worth it :).
"How were you doing reviews using SE80?"
By looking at the code (????) !!
Hi Eduardo Copat !
Great article "mandou bem"! (how we say in portuguese)
The git repository will most definitely take ABAP programming to another level.
Excellent piece of work!!!
What about to make the process more comfortable by adding one more development server. I hope +1 system is not so much expensive.
With at least two servers, you don't need to export zip content anymore. You can either start using branches or have more forked repositories like we do.
We have a central development server where we pull changes from an official GitHub repository. You can consider the server as a build server - we try to not code there, just pulling changes via abapGit and releasing them via transports.
Then we have a share sandbox server where we code and from which we push changes to our forked repositories. It is not possible to release any transport from the sandbox server, so we can use abapGit only.
For the bravest developers, we have a Docker image which they can run to get completely private ABAP development environment - no object locks, no transport locks, complete freedome. Again, no transport are available.
BTW, Jenkins job can run ABAT unit tests and ATC checks via SUT, but I guess you know that.
If only there was a way how to remotely control abapGit from a Jenkins job! We would get ABAP CI all other languages have 🙂
Given there are a couple of comments about how to use abapGit and the learning curve, I thought I'd mention there's an openSAP course on Git starting up SAP Cloud Platform Version Control with Git
I wrote my impressions of the into (week 0) here: https://blogs.sap.com/2018/04/13/get-into-git/
It's not language specific and definitely looks worthwhile for anyone like me fumbling their way through abapGit with just enough knowledge to get by.
Also, there's the option of running a local Git repo in your very own SAP system using abapGitServer. Things like automatic nightly commits are possible too.
Fantastic blog and excellent idea Eduardo Copat !
It got me seriously thinking into how to go down this approach for our code reviews.
The comment from Thomas Hammer above really nails the problem.
A transport could have objects across multiple packages.
Which means for the this to work, the ABAP package you are cloning to GIT has to be higher, i.e. containing more objects that hopefully encompasses all the transport objects.
The save approach is to take your top package (assuming you have one).
I tried cloning our top package that contains about 8000 objects (years of development). It is quite slow as abapGit took 4 mins to open the repository everytime as it has to serialise everything.
There are plans to make this faster in the future.
The issue with cloning at the top package also poses other problems.
I’ve notice there is a limitation in abapGit whereby once a package is cloned, it is no longer possible to clone a subpackage to another repo, or cloning the parent package to another repo.
Assuming if you go down this path to use abapGit for code review, it might be a challenge to use abapGit for anything else.
Developers are no longer free to clone their own packages as abapGit will not allow it (maybe I’m not using it right).
I noticed there is a feature in abapGit called "Transport to branch". This is perfect for what you are suggesting.
Look forward to hearing some feedback on this.
Follow https://github.com/larshp/abapGit/issues/1714 for progress on faster serialization.
Regarding package cloning limitations, this is currently a design decision in abapGit, suggest opening an issue for it, then we can look into alternatives.
Hi Eduardo, thanks for the introduction to abapgit! Do you think abapgit is more than code review only? What kind of other advantages does it have?
Hi Enyang, definitely not! You also have all the benefits of using a source code management tool, such as regular backups and versioning.
thanks for sharing your experience with abapGit. One question I have regarding the doubling of coding.
So what I understood:
On one hand the coding is stored in the ABAP system and on the other hand in the abapGit. So when you doing your reviews on the copied coding you can't be sure that you have the latest coding version in abapGit. Because it is a manually step someone can forget to do the push to abapGit.
Because abapGit is not included in the ABAP transport process youcan transport you coding changes without having it in abapGit.
Is this understanding correct? Our is there some automatic check or upload to git?
I ask because we also do our code reviews, but we do it directly in SE80 or Eclipse and do not use such a tool like git.
I see the disadvatange of copiing coding an daks myself how to avoid this disadvantage but having the advantage of git.
You are right, we are using like that. Although at the end of each Sprint we simply sync Git with what's in ABAP.
Yet, I think the advantages of using Git overcomes the disadvantages of manual code copying.
Ok, thanks for the answer
Thanks for the blog.
Does AbapGit only handle code reviews or does it also include transporting?
I was wondering what happens after the code reviews are done in AbapGit - I assume all the objects committed to Git are in transports (SE10), when the programmer first changed them?
Is abapGit essentially abandoned at that stage and normal transport release process to test and production takes over? Or does abapGit have some kind of transport functionality? If so, how does it handle conflicts with objects that might be in other transports?
abapGit does not care about transports. They are handled separately, as before.
If you are looking at a more integrated solution, gCTS might be interesting for you: https://blogs.sap.com/2019/11/14/gcts-is-here/ . There is also a longer Statement of Direction of what kind of CI/CD scenarios will become possible with gCTS: https://support.sap.com/content/dam/support/en_us/library/ssp/tools/Software-logistic-tools/Ideas_CI_ABAP_V3.pdf
Well, it all depends on what the user chooses to set up, abapGit has since earlier than Feburary 2018 had integration with transports via https://github.com/abapGit/abapGit/commits/10ea325ca879e4a759ac8d6550079154a62be896/src/zcl_abapgit_transport_2_branch.clas.abap
abapGit gives full flexibility to build all workflows, and updating to the latest is possible for SAP_BASIS 702 and up
also see https://blogs.sap.com/2020/01/30/how-we-do-abap-code-review-using-abapgit/