gCTS: git inside the Change and Transport System

gCTS approaches the problem from the other side. abapGit is a client that a developer runs; gCTS is part of the ABAP platform's change and transport system. SAP describes it as letting you store all versions of ABAP development and Customizing objects in git repositories. You keep developing in ADT and recording changes in transport requests, and gCTS turns released requests into commits.

What gCTS provides

• Storage of ABAP developments in git repositories on a git server, with several repositories per system (for example one per project and one for Customizing).
• The gCTS app (SAP Fiori app Git-Enabled Change and Transport Management) for cloning, committing, pushing and pulling.
• Support for nearly all development and Customizing object types; SAP Note 2888887 lists the restrictions.
• Updates of target systems by pulling commits, without the shared transport directory and import queues of classic CTS, and support for continuous integration pipelines, which SAP recommends for updating targets.

The process

By default, gCTS creates a commit in the local repository when a transport is released, then pushes it to the remote. If the push fails, for example because of missing rights on the git server, you push manually. You can also push individual objects before release, or implement a Business Add-In so that releasing a task creates a commit and push, which gives reviewers smaller increments.

vSID, transport layers and roles

gCTS needs a link between the transport system and a repository. Without the gCTS registry, that link is the vSID: a three-character virtual non-ABAP system of type VCS, unique in the transport landscape. The gCTS transport layer is named Z followed by the vSID, so a vSID of CAG gives layer ZCAG. Assigning a package to that layer makes it gCTS-managed; packages on classic layers keep using classic CTS. With the gCTS registry, the registry decides which repository an object goes to, and one vSID can serve all repositories in a system.

Creating a new vSID needs authorization object S_GCTS_SYS with activity 70 (Administer); without it you can only pick existing vSIDs. On a target system, each pull creates a change request whose number derives from the vSID, and that request is the container that imports and activates the objects.

For Customizing, SAP recommends a separate repository and the gCTS registry. Registered Customizing objects are assigned to the right repository when the request is released, and requests for Customizing no longer need a target system. Client-specific content records its source client in the repository, and the target client must match it. In practice this makes gCTS more attractive for landscapes that move a lot of configuration between systems with the same client layout, and less so for converted landscapes with many clients and legacy request habits.

SAP recommends updating target systems through CI pipelines rather than manual pulls. A pipeline can pull a commit into a test system, run ABAP Unit and ATC there, and report back to the pull request, which turns gCTS into the deployment step of a continuous integration flow. That is a bigger change to release management than adopting abapGit for review, so plan it as its own project with Luis and Sam, not as a side effect of introducing agents.

Limits to know before you choose gCTS

• SAP says that to transport requests for SAP Note corrections or modification adjustments you must continue to configure classic CTS (see SAP Note 2821718). A converted ECC system has plenty of both.
• TMS initial activation is still needed in every system, even if you use gCTS only.
• Client-specific Customizing pulls have known issues that SAP documents in its troubleshooting guide; test them before you rely on them.
• gCTS and abapGit artifacts aren't interoperable; SAP describes a one-time path to move abapGit content into a gCTS repository through a transport with the gCTS vSID as target.