New directions in Abap development with Git and the cloud

Whether it's a large development house or a medium-sized company with just a few developers - this is where the full potential of the interaction between SAP and well-known open source tools becomes apparent.

Almost every developer knows the advantages of the open source tools around Git: Automated procedures in the development process with continuous integration and continuous deployment, decentralized work of teams on a software, diverse possibilities of quality assurance through modern release processes and integrated version management are only some of the cornerstones. But how do you integrate Git into SAP development in a meaningful way?

For this purpose, there is the project abapGit by the Dane Lars Hvam, also known under his synonym larshp. The software is installed via transaction SE38 or SE80 by executing the complete 75,000 lines of source code.

Updates then work directly from the report. After installation, it is possible to clone Abap software projects from virtually any Git into the local Abap system. By the way, it doesn't matter which Git you use here. No matter whether public or on-premises in the own or outsourced data center.

But where is the big advantage now to connect to a Git server in an SAP system that already has sophisticated development mechanisms?

One added value can be that in the cloud, each developer is provided with their own development system outside of the normal transport structure, allowing each development to proceed independently.

Since these systems are only needed when they are being developed, they can be operated in virtually any cloud. To save costs, the unused systems are simply switched off during idle times.

The savings achieved in this way cannot be achieved with an on-premises installation, as the hardware must always be kept available. Young and imaginative specialists in particular can be given the opportunity to work without direct impact on the development system and to implement ideas without risk.

Conversely, of course, it is also possible to develop centrally in the classical way and to make a stable state of the software available in a fully automated manner in a QA system from the cloud. There, the software is now tested automatically or by a group of test users.

After that, the system can be deleted or paused. The automation as well as the documentation of these processes are done in Git. The former can be extended by any level and does not have to be limited to functional tests.

For example, advanced security tests can also be performed. With abaplint, automated code checks are also possible after each commit. The example of the development of abapGit itself, which runs publicly via Github using abapGit, shows how well this can work.

Another advantage arises for developments by SAP's software partners. For individual software it is true that similar functions are written again and again and the wheel is reinvented again and again.

New errors keep appearing or useful functions are missing. The effort for evaluation, testing and maintenance is therefore very high. By using a central Git, you can keep a stock of mature tools that you can fall back on as needed.

This can be done internally or shared with the open source community. At https://dotabap.org/ a platform with a collection of Abap projects already exists in the open source area.

In the SAP developer community, the idea of open source software is not yet widespread. However, with a generational change of developers, it can be assumed that more and more companies or developers will participate with small or large programs in their private time.

For job applications or CVs, it is nowadays almost mandatory to include your developments in a Github or Gitlab link.