You might already have heard about the Git-enabled Change and Transport System or gCTS in short. And if you found the idea somehow interesting, you might have wondered how to get started.
Well, the easiest thing is (after you configured gCTS) to start from scratch with a new ABAP package as a playground and / or new customizing, use the correct transport layer and see what happens on Git and how your packages and objects reach Git and from there the target systems – so that’s it. Go ahead.
But is that all? If you decide, maybe after a trial with a new package, that you like to use gCTS for more, you might want to migrate your existing packages that you currently handle with CTS to gCTS and use gCTS for your customizing changes, as well. This requires some additional effort and planning…
You can switch to gCTS for all your development and customizing at once. But there is no need to migrate everything at once. If you prefer a phased approach, you can migrate one development project (or package) after the other. gCTS and CTS can be used in parallel in one system This would allow you to take the time that you need to get familiar with the migration processes. Details what has to be done are described later in this blog post Once you decided to switch to gCTS for a certain package, you should not switch back to CTS again. At least, you should not switch from one to the other and back again several times. If in the end you come to the conclusion that you don’t want to continue with gCTS, you can of course switch back to CTS.
You can in principle switch the development of an application to gCTS instead of using CTS whenever you like. Some steps are required to migrate to gCTS that would interrupt the development process a bit. Therefore, please plan carefully when would be a suitable time to do the migration. The following list gives an idea about the required tasks and steps. It is sorted in the order things have to be done. So, start your migration project on top of the list and finish it with the last point. But read the whole list before you start 😉 and create a project plan in case you migrate bigger development projects.
- Configure gCTS in all systems of your landscape in general and prepare the required repositories – both on Git and connect them to your systems. Create separate repositories for workbench and customizing objects.
- Decide whether you would like to use the Registry. We recommend using the registry if your systems are on SAP S/4HANA 2020 FPS2 or higher. Especially if you use gCTS for Customizing, you should make use of the Registry as this saves you from adding the correct target system to the customizing request. You can find more information about the registry at gCTS Registry on the SAP Help Portal. A blog post describes what you have to do to integrate the registry into your development process: Integrating gCTS with Transport Organizer processes.
- Inform your developers and make sure that no development is done in the respective packages while you work on the following steps.
- Release all open transport requests that contain objects that shall be migrated to gCTS, and transport them through the complete landscape using CTS (so the ‘old’ way of transporting)
- Pre-fill your repository with the complete packages– you can use already released transport requests or the packages to do so. You don't need to collect all objects in a new transport request. It is required that a repository contains the package and all its objects. Partial objects are not sufficient. On the SAP Help Portal at Manually Push Objects you can find details on how to fill the repositories.
- If you decide against using the Registry: Change the transport layer of the packages that shall make use of gCTS. Editing Transport Attributes of Packages on the SAP Help Portal describes how this can be done
- Clone the completely filled repository to all systems before you start developing any new objects. Do not just clone it to development and then develop and only later clone it to the other systems of your landscape. See also the section ‘Caution’ below this list.
- If you would like to make use of the Registry: Register the repositories and all objects in the registry. Register also the customizing tables.
- Make sure that all developers have the right roles assigned to be able to work with gCTS. Authorization Concept in gCTS explains the details. Make sure that they have a user on your Git-provider. Give them access to the respective repositories by making them collaborators on the Git side and in the ABAP systems. For this, you can use the option to synchronize collaborators starting with SAP S/4HANA 2023. Details are provided on the SAP Help Portal at Use the Collaboration Tab of a Repository.
- Inform your developers that they can start developing in the respective package again. Let them know that from now on a commit in Git will be created when the release a transport request (or when they release a task if you decided to implement that: Integrating gCTS with Transport Organizer processes ). Tell them to maintain their credentials in the gCTS App.
Caution: gCTS can only delete objects that also reached the system via gCTS. If an object was already in the system before you used gCTS, then you delete it as part of a commit and then do other things in your repository that create new commits, the object cannot be deleted on other systems when you clone the repository. Similar behavior applies if you work on one system and switch to previous commits: objects that were not part of a previous commit but were deleted as part of a later commit cannot be restored when you switch to the earlier commit. This is the normal behavior of Git.
The best point in time to migrate a development project to gCTS is maybe when you have just finished and published a new release. Hopefully, this would be the point in time when all systems in your landscape are using the same software version. If this point in time doesn't exist in your development process, you have to carefully fill the repositories with the initial content: what is the version used in the production system should become the content of the main branch – and maybe also of the release branch if you decided to use one. If your development system is ahead of the main branch's content, then you could use the transport requests that had been created since the last release to push the respective object versions to the feature branch of your repository. Make sure that the required branch is the active one in the respective systems.
