Lesson 2 of 5
gCTS concepts
14 min
The classic Change and Transport System (CTS) moves ABAP objects as transport requests along fixed routes. It works, it is well understood, and it has no concept of branches, merges or a shared history outside the systems. The Git-enabled Change and Transport System (gCTS) uses Git as an external version management system for ABAP change and transport. SAP introduced it with SAP S/4HANA 1909, and SAP's support page states that it covers both workbench and customizing objects starting with SAP S/4HANA 2020.
How gCTS works
Developers keep working as before: changes are still recorded in transport requests in the development system. With gCTS, the current state of the objects is pushed to a remote Git repository as a commit, typically when the transport request is released, or during development if configured. Target systems then pull a specific commit from the repository into their local copy and import it, instead of importing a transport request from a queue. Each repository is tied to a virtual system ID that transports target, so the transport layer decides which objects are pushed.
- DevelopKenji changes objects in CMD, recorded in a transport request as usual
- Release and pushReleasing the transport pushes the objects to the remote Git repository as a commit
- Review and checkThe commit is visible in Git history; a pipeline can run checks on it
- PullThe test system pulls that commit into its local repository and imports the objects
- PromoteThe same commit is pulled into production when approved
Repositories, branches and roles
| Concept | Meaning | Contoso use |
|---|---|---|
| Repository | A Git repository holding one software component’s objects; ABAP systems have local repositories linked to the remote one | One repository for the custom order-to-cash extensions package |
| Virtual system ID | The target in the transport route that sends objects to the repository | Transports for that package target the repository’s virtual system |
| Commit | An immutable snapshot of objects with author and message | Every released transport becomes one; the commit ID is recorded on the Cloud ALM feature |
| Branch | A line of development; systems can be switched to a branch | Main for the train; a short-lived hotfix branch for urgent fixes |
| Pull and rollback | A system can pull a commit or branch state, and return to a previous state if an import fails | Test systems pull the train’s commit; rollback is tested before use |
Core gCTS concepts. Details vary by release; check the gCTS documentation for your S/4HANA version.
gCTS in pipelines
gCTS is what lets ABAP join a pipeline. The open-source SAP project "Piper" publishes pipeline steps for gCTS: creating or cloning a repository on an ABAP system, deploying a commit or branch to a system (with an option to roll back to the last working state if the deployment fails), and running ABAP Unit tests and ATC checks on the objects in a repository. The project documentation states that its gCTS deploy step can be used as of SAP S/4HANA 2020, and the quality-check step needs SAP S/4HANA 2020 with a specific SAP Note implemented.
When gCTS helps, and when it does not
- Is the system on SAP S/4HANA 1909 or later (2020 or later for customizing and pipeline steps)?Yes → continue · No → stay on CTS; ECC cannot use gCTS
- Do several teams change the same components in parallel, or do you need to deliver one codebase to several landscapes?Yes → gCTS adds real value · No → next question
- Do you want automated checks per change in a pipeline?Yes → gCTS is the practical route for ABAP · No → classic CTS with Cloud ALM may be enough
gCTS is not a requirement for continuous delivery. Many SAP teams get most of the benefit from small features, fixed trains, transport checks and automated regression on classic CTS orchestrated by Cloud ALM. gCTS pays off when parallel development, branching or pipeline automation is the bottleneck. In SAP S/4HANA Cloud Public Edition, SAP's support page notes a specific use: developing extensions in a one-system landscape and using gCTS to deploy them to a separate three-system landscape. Before you design around gCTS, check how your Cloud ALM release tracks gCTS-based deployments, since Cloud ALM's documented ABAP integration centers on CTS transports.
What would you do?
Contoso's ECC system is gone, S/4HANA 2025 is live, and two teams now change the same pricing extensions every month, often overwriting each other's work in CMD. Kenji asks whether gCTS would help. What is the best answer?
- gCTS uses Git as external version management for ABAP; introduced with S/4HANA 1909, workbench and customizing from 2020.
- Changes are still recorded in transports; releases push commits; targets pull commits.
- Repositories, virtual system IDs, commits, branches and rollback are the core concepts.
- Adopt gCTS when parallel development, multi-landscape delivery or pipelines are the bottleneck.
Check your understanding · not graded
Lesson check
1. With which release did SAP introduce gCTS?
2. In gCTS, how does a target system receive changes?
3. Are transport requests still used with gCTS?
4. Which open-source SAP project provides pipeline steps for gCTS?