Know your next commit (using ABAPGIT)

[jrgkraus]

Preface

This blog is being based on a system where ABAPGIT is installed. I will do some sort of screen cast in this blog.

Furthermore, GITLAB is used to host the repositories. Some of the screen shots are from this system. If you use a different GIT backend, the layout may differ. However, The screen shots I took from GITLAB are essentially functionalities of GIT, so your system should give similar information.

Origin of the idea

I refer this blog to an article from the book "97 things every programmer should know".

The author of the book is Kevlin Henney.

The article has been written by Dan Bergh Johnsson.

He is talking about how to break down the programmers task to small steps. After each step finished, do a commit. In terms of ABAP with ABAPGIT, the commit means a stage and commit in ABAPGIT.

As I tried to apply this in ABAP using ABAPGIT, I found it very inspiring. Instead of explaining, what I did, I decided to create a sort of screen cast.

The task

The actual task is to implement a mechanism that transfers data about warranty settings from an SD order header to an equipment. The transfer should be triggered by the release of a PP order that depends on an SD order. However, the type of the task does not really matter.

ABAPGIT

In ABAPGIT, I created branches for all affected repositories (we work like this: create a new branch when you start developing on a repo. If there is already a branch active, wait until it's finished and merged into master) and I flagged them with the favorite star:

Let's jump to GITLAB to see some commits I already made:

In my branch, I find the commits so far:

In a different repository, I did different things of course:

Planning the next commit

Reasoning a bit about my next step, I choose the creation of a queue table and coding for adding queue entries. I plan my next step in a way I can finish it within 1 or 2 hours. Let's go coding...

... 30 minutes later, I am finished with this step.

Let's look at the repository where I worked in:

Here we see, that I created a DB table, a data element, a types class and a class with interface for the DB insert with unit tests. Then I integrated  the queue class into the processing class that is called from the PP order  BAPI.

So I stage and commit:

Back in the repo list of ABAPGIT, I select the other package I worked on:

Here we see that some coding has been added to the DB_ACCESS and the factory class. Stage and commit again:

In the end, let's have a look at the commits so far:

Conclusion

This type of work flow seems to keep me focused on what I am doing. It constraints me also to reason about my next step time by time - which helps to structure my work.

Last but not least, a fine review about the actions taken has been created on GITLAB. Suppose a working step turns out to be wrong or bad implemented. Now, you can easily switch back to your last commit and restart.