Technical Articles
Software Lifecycle Management for SAP BTP ABAP Environment
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.
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/d62ed9d54a764c53990f25f0ab6c27f9.html
- 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/59656c2f858748fe976456248d390c5c.html - 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
Very good explanation!
Two days ago i searched for „abapGIT vs. gCTS“. Thanks for going into detail on that topic.
Is it possible to use an custom git installation with the software component instead of the hidden one that is created automaticly?
no, not as of today
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?
This is an interesting idea (“objects per user” layer), but it would require fundamental changes in the ABAP system.
True, it would require fundamental changes.
But as long as you state “an interesting idea”, I won’t give up hope
Plus: If done right it would be almost transparent to existing systems.
Thanks for the great explanation!
Do you have an estimate when the following features will 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
I removed the "Outlook" disclaimer from the section "Git Repository Branches and Maintenance (“Hot Fix”) Development". Branches are now available.
Hello Thomas,
do you already have some Guide or Help
that describes how to create a new branch?
We can see the buttons etc. but everything is greyed out.
kind regards
Stefan
Hi Stefan,
I added the link to the documentation in the blog post. See: "To create a new branch, select the branch that you want to create it from and click ‘+’." in the documentation.
A "how-to" guide that provides a best practice is planned.
Best regards,
Thomas
.
Hello Thomas,
there is currently no branch visible that we could use as master although transports have been released recently. Maybe a bug ? should we create an OSS Message ?
kind regards
Stefan Doktor
For each SW component, there must be an entry "master" in section "Branching" on the details screen of the SW component. If this is not the case, you should open an incident.
Hi Tomas,
Very nice blog.
I have a question, it is possible to have a similar architecture for on-premise sap landscape?
Eg: Abapgit -> DEV -> gCTS -> TST -> gCTS -> QA -> gCTS -> PROD
As CI/CD pipeline
Thanks,
Pankaj Valecha
Hi,
for onPremise Landscapes, we also offer pipeline steps in Project ' Piper' that you can use to set-up a pipeline.
There are five steps available - all staring with 'gcts'. Two are made more for the Set-up parts: gctsCreateRepository and gctsCloneRepository and . Three are made for the day-to-day work: gctsDeploy, gctsExecuteABAPUnitTests and gctsRollback.
You can make use of them to set up your pipelines. Please be aware that the gCTSRollback is made for going back to a previous commit only in a short test cycle or something alike. It will deploy the version of the objects that is available in that previous commit without any respect to data that might have been created using the newer version. E.g. if database table had been extended and is becoming smaller again after the rollback, the data that requires the extended version is lost.
Why would you need ABAPGit to get objects into your development system? If you already have your onPremise landscape in place and develop on the Dev system, then you don't need ABAPGit to migrate any content into that system.
ABAPGit is not directly connected to gCTS. You could use it to get development objects into your ABAP system - no restrictions on that. But you would need to set up gCTS and export the objects in Dev using a transport request that is designed to create a commit. Configuring gCTS is described on the SAP Help Portal.
Please also note that gCTS is available starting with SAP S/4HANA 1909 and if you would like to use it for customizing data, then SAP S/4HANA 2020 is required
Hope this helps a bit - let me know if not
Kind regards
karin
Hi Karin Spiegel,
Thank you very much for your detail explanation.
with respect to AbapGit, I am using it for triggering CI pipeline to do code checks and unit tests on DEV system before any code transport.
For CD purpose I was considering gCTS with SAP S/4 HANA 1909 system and Plan to use the its rest API and design a small CD pipeline but Piped piper is something which is already doing the same.
Thanks,
Pankaj Valecha
Yes in principle gCTS is released for on-premise also. Please refer to the links under "gCTS", "General". But I am not an expert in gCTS for on-premise. I will forward your question to my colleagues that work in this area.
Hello Thomas Schneider
Actually I asked this question in this thread
So there are two gCTS one for one premise and the other for ABAP environment right ? .
I was having some confusion around it
Yes and no.
Bring your own Git is also planned for SAP BTP ABAP, but not yet available.
Dear Thomas Schneider ,
Is "Bring your own Git is also planned for SAP BTP ABAP" available now?
Thanks,
Mainak