Skip to Content

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

Our approach

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.

Story time

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!

 

 

To report this post you need to login first.

17 Comments

You must be Logged on to comment or reply to a post.

  1. Michelle Crapo

    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!

    Thank you,

    Michelle

    (1) 
    1. Eduardo Copat Post author

      Hi, Alexander,

      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:

      1. One that checks abaplint on the master  branch
      2. One that runs all unit tests and calculate their coverage
      3. One that runs ATC checks
      (2) 
  2. Thomas Hammer

    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.

    Thank you.

    (1) 
    1. Paulo Buettenbender

      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)

      (0) 
  3. Jonathan Viau

    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) 
    1. Eduardo Copat Post author

      Hi, Jonathan,

       

      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 would like to be convinced that it overall brings us more value than overhead to use ABAP Git.

      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.

       

      (0) 
  4. Marco Hernandez

    Hi Eduardo,

    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.

    (0) 
    1. Eduardo Copat Post author

      what prevents anyone for making changes in the code base, which lives in the ABAP repository, and not committing anything to git?

      Nothing… you will need to count on ethics and professionalism.

      (0) 
    2. Jakub Filak

      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:

      https://github.com/tobiashofmann/sap-nw-abap-docker

      (1) 
    1. Eduardo Copat Post author

      Hi, Guy,

       

      How were you doing reviews using SE80?

      I suggest you try using the approach I mentioned and check if it is worth it :).

      (1) 
  5. Jakub Filak

    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 🙂

    (0) 
  6. Mike Pokraka

    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.

    (0) 

Leave a Reply