Skip to Content
Technical Articles

Software Lifecycle Management for SAP Cloud Platform ABAP Environment

SAP Cloud Platform ABAP Environment is available for one year now, and users are running more and more productive apps in this environment. Due to the criticality of changes, customers maintain and verify changes of custom application in development and/or test/quality systems first, before they transfer the verified content in a controlled way to the production system. Thus, software lifecycle management is getting a critical aspect.
A tutorial Transport a Software Component Between Two ABAP Systems is available on the technical aspects of the software lifecycle management. In this blog post, I want to give some more background on the topic.

Excursus: abapGit and gCTS

Before we start digging in the details of software lifecycle management, I must spend some words on abapGit and gCTS. Two independent solutions were started in parallel to address the usage of Git in ABAP, one coming from the open source community (abapGit) and the other from SAP itself (gCTS).

  • abapGit is an open source project founded by SAP community in 2014. SAP contributes to this project since 2018 with a significant number of contributions. It is available for SAP ABAP platform on-premise versions 7.02 or higher and for the SAP Cloud Platform ABAP Environment.
  • gCTS is an enhancement of the well-known Change and Transport Management System (CTS) provided by SAP. It is available for on-premise versions 1909 and for the SAP Cloud Platform ABAP Environment.

With this blog I do not want to discuss the pros and cons of the 2 solutions, but concentrate on clarifying the use cases. Due to the availability and architecture, abapGit and gCTS fulfill complementary use cases in the context of the SAP Cloud Platform ABAP Environment. (As we are concentrating on SAP Cloud Platform ABAP Environment here, I want to list the use cases that are related to this environment here only).

For abapGit, we see the use cases:

gCTS is used for transports between systems within an SAP Cloud Platform global account. The remainder of this blog posts concentrates on this scenario.

In the appendix of this blog post, I have added links for further reading on abapGit and gCTS.

Setting Up Your Software Lifecycle Management

Figure 1 shows the classical 3-system setup of a development system, test system and production system. Each system is located in a dedicated sub-account (or space) so that all resources/services that belong to the development, test, or production environment are separated from each other (e.g. additional services such as UIs, connectivity, etc.). The setup can be enhanced by pre-production systems, multiple test systems, etc. Test systems can be provisioned on demand (temporary) or permanently.


Figure 1: Export / import via Git repository between systems in an SAP Cloud Platform global account (gCTS) and beyond (abapGit)

During system setup, you can set the parameter is_development_allowed. If this parameter is set to false, the custom software components are set to not modifiable. Software changes can only be imported via transport management. See: documentation.

In the development system, you create your software components:

  • The software component ZLOCAL is available by default. Objects assigned to this software components cannot be transported.
  • Create your software components with the Fiori app “Manage Software Components” (available in the Administrator role template) and import (pull) it into the system. With this step a software component is created in the ABAP system and a Git repository is related to it.
  • If you want to transport business configuration content across ABAP systems, create a software component of type “Business Configuration”.

The steps are described in the tutorial Transport a Software Component Between Two ABAP Systems in detail.

There is no recommendation on how many software components you should create. But you must consider that the object of one software component cannot be used in another software component by default, because software components provide their functionality via explicitly released APIs to other software components. Consequently, you must set the API state of the object to “Released”, if you want to use the object from another software component (see documentation , documentation).

As of today, you cannot move development objects from one software component to another. So the introduction of software components should be planned carefully.

You can use ABAP namespace in SAP Cloud Platform ABAP Environment. If you have registered a namespace at SAP, it will be provided automatically during provisioning. For customer projects, a namespace is optional.

After creation of software components, developers can create ABAP packages and objects in software components and assign them to transport requests. Once a transport is released, the objects are pushed into the respective Git repository. You can create, manage, and release transport request using the Transport Organizer in the Eclipse-based ABAP development tools. In other words: developers work with transport requests and tasks in the same way as in on-premise systems (but, of course, in the Eclipse-based ABAP development tools).

For an SAP Cloud Platform ABAP Environment, a Git repository for gCTS is automatically configured, when you provision an ABAP instance. It is completely managed by the ABAP server (with the Fiori app “Manage Software Components” or with the communication scenario “Test Integration”, see below). This means, users of the ABAP Environment do not have direct access to the Git repository, but the access is tunneled through the ABAP server. This approach has the advantage for you, that the configuration and management of Git is completely invisible for you, and you as a developer can start immediately using the transport management without configuration. The visibility of the Git repository is restricted to SAP Cloud Platform ABAP Environment systems that belong to one global account. On the other hand, the approach restricts the Git functionality to the features that are exposed by the ABAP server. For abapGit, you bring your own Git, which is just the opposite approach, meaning that you have all its flexibility and configuration options.

Basic change logging using the “traditional” ABAP server capabilities is available in the development system such as:

  • Revision History for ABAP objects
  • Transport Logging
  • Responsible and Last Changed By contacts

As of today, we recommend not to decommission the development system as the Git repository alone cannot ensure a save change logging today. It is planned to remove this technical restriction so that you can provide and decommission development systems on demand.

An integrated software lifecycle management for dependencies to non-ABAP objects (e.g. UIs) in the SAP Cloud Platform is currently not available. The integration of ABAP content into the concept of Cloud TMS and Multi-Target Applications (MTA) is planned to meet the requirement of an integrated software lifecycle management.

Use the Fiori app “Manage Software Components” for import (pull) of the software component into test or production systems. In contrast to the “traditional” CTS, you cannot import single transports, but only the latest version of the Git repository.

Outlook: Git Repository Branches and Maintenance (“Hot Fix”) Development

Planned for future version, Git repository branches can be used to control the flow of changes through the test and production landscape. Once tests are successfully completed, a new release branch is created, which can be pulled (imported) into the production system. This feature will allow better control of changes, which are applied to production systems (Figure 2).

Figure 2: Support of Git branches (planned)

Figure 3 shows how an approach for maintenance (“hot fix”) development based on release branches could look like: If a fix is needed, the release branch is pulled into a maintenance system. The fix is developed in the maintenance system and pushed into the release branch. After successful testing in a maintenance test system (which can be provisioned on-demand), the fix can be pulled into the production system. The fix must be implemented in the development system in parallel.

Figure 3: Maintenance (“hot fix”) development based on Git repository branches

 

Outlook: Continuous Integration / Continuous Delivery (CI/CD)

The use of Git as the single source of truth and the ability of providing und decommissioning ready-to-use ABAP systems opens the opportunity for modern continuous integration / continuous delivery (CI/CD) approaches. SAP will invest in this direction and – although it is not mandatory for customers to follow this approach – we recommend that customers should investigate in this approach.

The communication scenario “Test Integration” (available with 1911, see documentation)  offers services, which can be used as part of a CI test pipeline. With 1911, the first service is available for triggering an import of objects of a software component from a Git repository and poll the status of the import. More services are to come and I will provide an additional blog to share ideas here.

Appendix: Links / Material

abapGit

gCTS

9 Comments
You must be Logged on to comment or reply to a post.
  • Thanks for the explanation. Together with the information you provided in the partner workshop I have a much clearer picture of the planned use-case differences between gCTS and abapGit.

    One question, though: Are there any plans to extend the git support in SAP systems to a point where branched development becomes possible similar to how a developer works with git in other languages?
    In theory that would be possible if the HANA DB includes a transparent “objects per user” layer (similar to the client in todays systems) that defaults to the main “Branch” if no user object exists, would it not?

  • Thanks for the great explanation!

    Do you have an estimate when the following features will be available:

    • Git repository Branches
    • Deployment via MTA
    • Support for SAP Solution Manager or similar features (e.g. ChaRM); Or is this going to be “replaced” by SAP’s Cloud Application Lifecycle Management (CALM)? And if yes, when will that be available?

     

    Also am I understanding the following, concerning the service released in 1911, correcty:

    The Git Repository in the ABAP Environment is not accessible by the developer. Instead you have a REST API over which you manage the Git Repository (inside the ABAP Environment). The released service allows one to start a Pull request (via the REST API) to pull code from another Git repository (for example hosted on github) to the Git repository inside the ABAP Environment.

    Assuming I understand this correcty, why hide the Git repository behind a REST API instead of allowing the developer (or CI/CD Server) to access it directy? This way it requires one more Git repository and the developer cannot profit of any Git functionality inside the ABAP Environment.

     

    Thank you very much and I look forward to your reply.

     

    Sincerely

    Marco Hirsbrunner

    • Unfortunately I cannot comment on the product roadmap and the availability of features. But all 4 points are well known, and SAP must provide answer for them. Please refer to the official roadmap. The link to the last roadmap is https://blogs.sap.com/2019/06/19/the-abap-platform-strategy/ , but this is outdated. A new roadmap should be available within the next weeks. I will comment on the updates regarding gCTS and abapGit here.

      Now your last question on an “bring your own Git” approach for gCTS and SAP Cloud Platform ABAP Environment. This is of course a valid requirement, but currently the error handling of gCTS is simply not not good enough for a Cloud product. Let me explain: gCTS in SAP Cloud Platform ABAP Environment supports a wide scope of dev/customizing objects, and it is supposed to be used for imports into dev/test and prod systems. If we open up Git for gCTS, developers will be able to manipulate the files (e.g. doing fixes, cherry picking, … in Git). This introduces a complete new class of error situations for the ABAP transport system. Unfortunately it takes time to go over each and every dev/customizing object and improve the error handling so that it meets your and our quality requirements. This is why we start with an closed Git approach.

      In contrast, for abapGit we have already an “bring your own Git” approach, which comes with 2 limitations: (1) a smaller number of dev objects is supported (2) Import into prod instances is not supported. (I hope that from my previous explanation, you get the reason why).

      Does this explanation help?

      Best, Thomas

       

       

      • Hello Thomas,

         

        thank you for the quick and helpful reply!

        I am looking forward to the roadmap in this case!

        Yes, the explanation clarifies a lot of things for me.

         

        Greetings,

        Marco Hirsbrunner