Application Development and Automation Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
GrahamRobbo
SAP Mentor
SAP Mentor
69,493
Are you an ABAP developer? Are you using abapGit?



If you answered "Yes" to the first question did you answer "Yes" to the second question too?

You might be thinking - "What is abapGit?" - so let's start there. The simple answer is that abapGit is a Git client written in ABAP for ABAP.

Some of you are now thinking "What is Git?". I'm sorry that is outside the scope of this post but please, please, please use Google to figure that out. And I urge you do it quickly - like "now" - and then return to this post later. Git is a fundamental part of the contemporary developer's toolkit. IMO ignoring Git is not an option for developers in 2017.

Back to the topic at hand. abapGit is an Open-source project initiated bylars.hvam under an MIT License.

At time of writing there are 24 contributors to the abapGit project. There have been over 400 commits in the past 5 months alone which shows this is a very active and vibrant project. Maybe you too will want to contribute and help make abapGit bigger and better?



One of the design goals of abapGit is that it should have a "small footprint". This can mean many things to many people. One thing is it is absolutely the easiest ABAP project to install - EVER! No transports. No multiple steps. No pre-install of other things. No file uploads. No patches required. No add-ins required. Simply copy and paste code into a program on your ABAP development system and activate.

Like this....



The first thing you might want to do after installation is connect to GitHub so you can keep your abapGit code up to date. Yeah - amazing concept isn't it? We can pull down the latest version of the abapGit project any time we like. Kapow! Take that CTS! abapGit also has a "background mode" so you can automate this task.



You are highly likely to want to use GitHub for some of your repositories anyway. It is the most popular hosted Git out there, it is free, and it contains some other awesome ABAP Open-source projects like abap2xlxs.

For abapGit to talk to GitHub we have to use TLS. This means we have to install some root certificates on our ABAP system using transaction STRUST. The abapGit installation documentation takes you through how to get these certificates and install them. And there is also a simple test program so you can ensure the connection to GitHub works.

If you want to connect abapGit to other Git servers they may well mandate you use TLS as well and therefore you might have to install other root certificates depending who their CA is.

So now that is done, let's see how we can link to the abapGit repository on GitHub so we can keep our installed abapGit code up to date with the latest developments. There is a wizard to help you do this in a few clicks of the mouse.

When abapGit is run for the first time it will take you to the abapGit tutorial page. You can also find this via the menu Help->Tutorial. Simply click on the "install abapGit repo" link to kick off the process. You will be asked to confirm that you want to install into package $ABAPGIT. abapGit links Git repositories (repos) to ABAP packages. So we need to store the abapGit artifacts in a local package of their own - in this case $ABAPGIT. You will also be asked if you want to overwrite the ZABAPGIT program you just created. Answer "Ok" to this. Activate all the abapGit artifacts and you are done.



To finalise this post - and hopefully to leave you with just one example of how abapGit changes the game for ABAP developers let me take you through a simple scenario. We need to start by cloning a repo to an ABAP package. I am going to use the sample code from my recent presentations on Building Gateway Services which can be found at https://github.com/grahamrobbo/teched16_example.



See how easy that was? A few clicks here and there and I have all that ABAP code pulled down from GitHub into a package I was able to create from inside the abapGit UI including activated everything. Kapow!



Now watch as I stupidly decide that my code needs a little too much refactoring. I brilliantly decide to delete the interface ZIF_GW_METHODS because I have forgotten how this is used all over the place. Suddenly I have lost important code, the stuff I have is broken, and I can't activate anything. Arrrggghhhh. I guess I will have to logon to the production system and copy and paste the old code from there to get me back on track? Assuming I can remember all the other changes I had in progress as well.

Or - I can just refresh my package from the latest commit on my GitHub repo. And because I "commit early and commit often" I have lost none of my work in progress either.



Kapow!

And that is just one benefit of bringing Git to the ABAP developer toolset.



 

RIP Adam West

Thankyou SAPlink

 

BREAKING NEWS BREAKING NEWS BREAKING NEWS BREAKING NEWS BREAKING NEWS 

In his SAP TechEd Las Vegas keynote presentation Bjoern Goerke announced that "we (SAP) are going to work with the SAP Mentors to embed this (abapGit) into the ABAP design-time".

You can hear this announcement and see Bjoern's demo around the 41 minute mark of the keynote presentation replay.
69 Comments
GrahamRobbo
SAP Mentor
SAP Mentor
0 Kudos
Absolutely for distributed development. +100
Will2
Explorer
Hi,

Does AbapGit also include transporting (STMS)?

I was wondering what happens after the code reviews are done in AbapGit – I assume all the objects committed to Git were initially locked in transports (SE10) on the development system, when the programmer first changed them?

Does abapGit have some kind of transport functionality? If so, how does it handle conflicts with objects that might be in other transports?

Thanks
William
GrahamRobbo
SAP Mentor
SAP Mentor
0 Kudos
Hi William,

when explaining the respective responsibilities of abapGit and CTS I try to define them by their very different goals.

abapGit is about code management, including versioning, branching, merging, etc. while you are building code in your development environment.

CTS is about code promotion, i.e. moving code from your development environment to downstream systems/landscapes.

These are gross oversimplifications but for me abapGit is a tool for developers who are building code whilst CTS is a tool to deploy the finished code to downstream systems.

I see them as two very different tools. Others disagree. 😉

So the answer is "No" abapGit does not have some kind of transport functionality although it does allow you to pull down ABAP artifacts into your development system.

I hope that all makes sense.

Cheers

Graham Robbo

 
BaerbelWinkler
SAP Champion
SAP Champion

graham.robinson

Hi Graham,

thanks for this blog post! I’m wondering if the ABAPGit program can help me with the following scenario:

  • I’ve been doing some prototyping in a sandbox system
  • created objects are in different transports, packages and $tmp
  • ABAPGit is available as a Z-program in the system
  • there’s no connection to Github (and there’ll be none because a) our sandbox systems are standalone and b) I wouldn’t be able to establish a connection as described to outside systems anyway)
  • the sandbox system will be refreshed sometime early next year
  • I’d like to keep the prototyped code and objects somewhere and re-create them after the refresh to continue where I left off

I already tried to save objects via “Advanced –> Transport to zip” and have those files saved locally. What I don’t immediately see is an option to use those files to simply “re-import” them after the refresh. Am I looking in the wrong place if I expect to see the counterpart activity under “Advanced”? And is ABAPGit even suitable for what I’d like to do?

Thanks much and Cheers

Bärbel

 

GrahamRobbo
SAP Mentor
SAP Mentor
0 Kudos
Hi Bärbel,

glad you are seeing the value of abapGit.

To import a .zip to a package you first need to create an offline project using the +Offline menu.

Then you should be right to go.



 

But probably a better way to do it - assuming all your ABAP artifacts can be placed in the same package - is to define that package as an offline abapGit project and simply export it to a .zip rather than export a transport to a .zip.

Cheers

Graham Robbo

Former Member
Hi all,

I'm a true Git fan but I'm puzzled when it comes to understand how the main and great benefit from Git can apply to SAP development : having multiple developpers contributing to the same source on the same environnement?

Because the beauty of Git is the distributed architecture which I can't figure out with SAP "all in one place and one and only one active version at a time" paradigm...

What did I missed ?

Cheers!

Seb
GrahamRobbo
SAP Mentor
SAP Mentor
Hi Seb,

thanks for your comments - you raise some good points. Many of these have been discussed in other areas such as the abapGit slack channel (abapgit.slack.com) and at various SAP Inside Tracks and other less informal meetups - so let me start with a quick brain-dump of some of the things I find most useful when I am using abapGit to assist my ABAP development.

The most obvious benefit for me is that I can revert to any previous commit quickly and easily. SAP tools provide some support for reverting to previous versions but they are very object centric - whereas the git perspective is repository centric.

I'm not saying this ever happens to me 😉 but if I was to decide to refactor some of my code, maybe break some methods down into multiple smaller more manageable ones, change some data structures, remove some obsolete methods from an interface or two, etc. I might find I have gone down a deep rabbit hole and unintentionally broken things. Maybe a whole lot of dependencies I wasn't aware of are now broken. Now I can't even activate a whole bunch of stuff. I might struggle to even identify all the unintended consequences of my brilliant plan to improve my code. As I said - this would never happen to me.

A few simple code changes might be easy to revert. Perhaps I could use the SAP tools to do that - but we all know (don't tell anyone) that it is easier to just log on to the QA or PRD system to copy and paste the code back into the DEV system. Problem solved. But what about if I had changed many ABAP artifacts? Perhaps dozens or even hundreds? What if I have made changes to non-code artifacts like data dictionary objects that can't simply be copy and pasted back? A full system restore because one developer lost control of his changes seems a bit drastic - and disruptive.

But with abapGit I can just do a "Reset Local" and in seconds I am back to my last commit. Or I could delete my feature branch and create a new one from the master branch to start all over again.



Similarly when building something new I may have a few different ideas about the best way to do it. So I can create a new branch for each idea, start coding, and then I can quickly switch between each branch as I try different ways to solve the problem. Once I have chosen the best one I keep that branch and delete the others.

I am sure these examples give you ideas for many more.

However your point about SAP's “all in one place and one and only one active version at a time” paradigm is spot on too. abapGit can help here because using the git branch concept you can have multiple versions but this doesn't help you with only being able to have one active version in your ABAP system.

I believe the way forward must include discarding the concept that all developers have to share the one provisioned environment. Why can't each developer have their own environment - as they do in most other languages? Modern infrastructure concepts like machine virtualisation, containerisation, etc. make this much easier to achieve than it ever has been before. The Steampunk environment currently provisions a new instance in about 20 minutes I am told. If not a development environment per developer at least per project or per team?

I envisage that a developer could provision their own development environment - which in most respects would be almost a copy of the existing production system. Most organisations take a snapshot of their production system every night. The Friday night snapshot could feed into an automatic process that creates a new "developer" snapshot with a subset of data, anonymisation of data, etc. When the developer chooses to instantiate a new developer environment it takes the latest "developer" snapshot, allows them to nominate abapGit repositories/branches that are required (in lieu of another package management solution) and provisions that instance for them. Hopefully in minutes - not hours.

These new "developer" instances would not require any permanent tracking of changes or inclusion in the good old "transport landscape". They need to be totally independent so that they can be provisioned and discarded without impacting any other system or landscape. Developers would need to "commit early and commit often". This means their developments are no longer tracked inside a nicely managed ABAP system but in a git repository. They can build away to their hearts content but mindful that no one is backing up their ABAP development system - unless they do it themselves. The one source of the ABAP truth is in the git repositories.

Once they are ready the changes can be merged into the master branch which is being tracked by another ABAP system that is recording changes - so they go into transports - and there the developments can be tested and moved through the system landscape until they make it to production in the same way they do now.

Just my 2 cents worth. 😉
MarcelloUrbani
Active Contributor
Currently playing with similar ideas, not practicing yet

Have a docker instance on aws, can start a new instance from the command line in a few minutes.

Did it for a demo in teched, thinking about doing the same for real, at least as an experiment.

Btw, why stop at development? I'd like to have my QA done the same way 😉

 

The real issue is customising, still have to try configuration sets or what they are called
GrahamRobbo
SAP Mentor
SAP Mentor
Awesome stuff Marcello.

Why stop at development? Because it freaks people out. 😉 The same reason I didn't mention why not have production just pull it's code directly from a git repo instead of having to move it through a transport landscape. LOL

Yep - configuration is a problem yet to be solved.

Cheers

Graham Robbo
MarcelloUrbani
Active Contributor
0 Kudos

Honestly I would stick with transports for the time being for the last 2 steps: regression test and production. Partly because I sell a transport related product ? , but mostly because of configuration and the fact that git pulls are still unreliable with sizeable codebases. I can deal with that in DEV/QA, not in prod.

PS: I want a regression test system to validate the stuff I send to production. Ideally with full automated test, but even a bit of smoke test is better than nothing. And I can ensure the transports import correctly too

0 Kudos
How do I start contributing to abapGit project? I have created a fork but not sure which folder to be pulled from the repository to make the changes?
GrahamRobbo
SAP Mentor
SAP Mentor
0 Kudos
Contribution guidelines are here .
former_member645535
Discoverer
0 Kudos

Good blog content, graham.robinson ,

I have a query related to security, since we need to copy the code from abapgit text file and create a report. Doesn't this be a security violation.

 

 

larshp
Active Contributor
see https://docs.abapgit.org/#security

You are free to read through the code, as of right now there are 118 people watching the repository, getting notifications about every change, I'd say all code is reviewed by many more people than average ABAP code.
former_member645535
Discoverer
0 Kudos

Thanks lars.hvam

So we can copy the code from zabapgit.abap as mentioned in the URL https://docs.abapgit.org/#security and reuse in our environment. Correct?

 

larshp
Active Contributor
0 Kudos
Yes

abapGit is provided as clear text, also all repositories being installed is in clear text, allowing developers to read and understand the change before importing. With classic transports, the content cannot(?) be investigated before import.
michael_calekta
Explorer
0 Kudos
I like AbapGit a lot and used it for saving my developments I made so far. Yet there's a little problem. I had stored my developments under a huge dev-package in a single zip-file, Now I would like to include just one program and a certain class of it into my actual development environment, without having to pull all the other stuff. Is there a possibility to do this easily? Somehow I couldn't find out how to do it.

Thanks for any help.
larshp
Active Contributor
If you have a zip file, just unzip it, delete the unnecessary files, zip it again and import that.

Alternatively when pulling, you can choose which objects to import, https://github.com/abapGit/abapGit/pull/5985
michael_calekta
Explorer
0 Kudos
Thank you for your quick reply!
Deleting the unnecessary stuff finally did the trick - so easy, that I just couldn't see this simple solution. The other alternative didn't really work, as the program seems to do all the checks for all the items, although just a few are selected. Anyways - deleting the unneeded is much easier and quicker. Great help!