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:

◉ On-prem to Cloud code migration

◉ Cloud to on-premise transfer (“Cloud First“ approach)

◉ Export of coding when system is decommissioned

◉ Cloud to Cloud transfer (share code with others, for example as open source, or from a partner to a customer account)

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)

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”.

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.

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” 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.