- SAP Managed Tags
SAP BTP 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.
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).
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.
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 steps are described in the tutorial Transport a Software Component Between Two ABAP Systems in detail.
Software components can be used for organizing developments that are completely separated or only loosely coupled in separated software components.
You should consider:
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:
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.
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
For details, see
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. SAP deliveres service for creation/configuration/deletion of ABAP systems, triggering an import of objects of a software component from a Git repository, run ATC checks, etc. The blog post CI/CD Tools for SAP Cloud Platform ABAP Environment describes the topic in detail. You can find also links in the appendix.
abapGit
gCTS
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: see the tutorial Use abapGit to Transform ABAP Source Code to the Cloud and the blog post How to bring your ABAP custom code to SAP BTP ABAP Environment
- 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 transfer code from a global account of partner to a customer global account)
- Implement mechanisms for distributed development and testing in dedicated development/test ABAP systems. This could be useful for special projects such as proof of concepts or features that are dependent on regular development of a solution but shall run independent from its lifecycle.
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”. For details on how to work with business configuration data, see my blog post Business Configuration for SAP Cloud Platform ABAP Environment.
The steps are described in the tutorial Transport a Software Component Between Two ABAP Systems in detail.
Software components can be used for organizing developments that are completely separated or only loosely coupled in separated software components.
You should consider:
- 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).
- Software components should not have cyclic dependencies (= objects in software component B use objects in software component B and vice versa). If you create dependencies between SW component, we recommend that you do this in a layered way, for example for grouping basic re-use functions in a dedicated SW component.
- In gCTS a software component is represented by a Git repository. Thus, transport requests and releases are separated by software component and have therefore an independent lifecycle.
- As of today, you cannot move development objects from one software component to another. Thus, the introduction of software components should be planned carefully.
- You can use one system landscape for development and testing for all your software components. Release cycles for software components can be even independent from each other (depends on the dependencies, but this is not limited by technology).
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.
Git Repository Branches and Maintenance (“Hot Fix”) Development
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
For details, see
- the documentation on Software Component Lifecycle Management (Manage Software Components ) -> How to Work with Branches.
- the documentation on provides a step-by-step guide on how you can work in a 3-system-landscape and in a 5-system-landscape: Setting Up and Working with Your Landscape
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. SAP deliveres service for creation/configuration/deletion of ABAP systems, triggering an import of objects of a software component from a Git repository, run ATC checks, etc. The blog post CI/CD Tools for SAP Cloud Platform ABAP Environment describes the topic in detail. You can find also links in the appendix.
Appendix: Links / Material
abapGit
- General
- abapGit open source project
https://github.com/larshp/abapGit - Documentation: https://docs.abapgit.org
- "Marketplace": org
- abapGit open source project
- SAP Cloud Platform ABAP Environment
- Documentation "Importing Code with abapGit" https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/d62ed9d54a764c53990f25f0ab6...
- Tutorial "Use abapGit to Transform ABAP Source Code to the Cloud" https://developers.sap.com/tutorials/abap-environment-abapgit.html
- Tutorial "Transfer Your ABAP Source Code With SAP Cloud Platform ABAP Environment via abapGit" https://developers.sap.com/tutorials/abap-environment-abapgit-transfer.html
- Eclipse plugin for ABAP PaaS: https://github.com/abapGit/ADT_Frontend
gCTS
- General
- Blog post gCTS is here
- gCTS Statement of Direction
- Central note 2827411
- Documentation
- SAP Cloud Platform ABAP Environment
- Documentation Software Component Lifecycle Management
https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/59656c2f858748fe976456248d3... - Tutorial "Transport a Software Component Between Test and Development Systems"
https://developers.sap.com/tutorials/abap-environment-gcts.html - Blog post: SAP Cloud Platform, ABAP Environment – Lifecycle Management – Introduction
- Blog post: SAP Cloud Platform, ABAP Environment – Lifecycle Management – sample scenarios
- Documentation Software Component Lifecycle Management
- SAP Cloud Platform ABAP Environment, CI/CD
- Documentation for communication scenario “Test Integration”:
- Related services in the piper library:
- Provide an ABAP instance: https://sap.github.io/jenkins-library/steps/cloudFoundryCreateService/
- Configure a communication scenario for an ABAP instance: https://sap.github.io/jenkins-library/steps/cloudFoundryCreateServiceKey/
- Pull Git Repository: https://sap.github.io/jenkins-library/steps/abapEnvironmentPullGitRepo/
- Run ATC check https://sap.github.io/jenkins-library/steps/abapEnvironmentRunATCCheck/
- Blog post: CI/CD Tools for SAP Cloud Platform ABAP Environment
22 Comments
| User | Count |
|---|---|
| 60 | |
| 20 | |
| 11 | |
| 11 | |
| 8 | |
| 8 | |
| 8 | |
| 6 | |
| 6 | |
| 6 |
