Introduction Change Request Management (ChaRM) controls change and transport process for ABAP system landscape which is based on classic Change and Transport System (CTS), but since SAP Solution Manager 7.2 SP12 ChaRM integrated with Git-enabled Change and Transport System (gCTS) to provide a possibility to transport ABAP code using Git-enabled CTS instead of CTS. A new change document type introduced to support the change management process. By default, Git-enabled changes are delivered as change transaction SMGH. Prerequisite In order to run Git-enabled Change process you have to be prepared, first you have to configure gCTS for ChaRM, refer to the online help Configuring Git-enabled CTS. To get a better understanding about Git-enabled Change, you can refer to online help Processing Git-enabled Changes. Working with Git-enabled Change Add your managed gCTS system (SAP_BASIS 755 SP00 and higher) to your Solution according to their system roles even they don’t have transport routes connected. E.g., take H18 as the development system, H19 as the testing system and H17 as the production system in the Solution definition, but they are seperated systems without transport routes. Git-enabled Change supports all kinds of Change Cycles (Continual Cycle, Phase Cycle and Release Cycle), you have to build the transport track for your gCTS landscape manually during the tasklist creation of Change Cycle. Because in fact the gCTS systems are isolated from each other and you have to create the “transport routes” in your mind and connect them by system roles they acted, ChaRM will detected the valid gCTS systems and you only have to assign them to related system roles. Git-enabled Change support gCTS landscape with mutiple target systems and production systems, each target system or production system has an equal position in its role. Once tasklist created, you will see what a gCTS transport track looks like in the landscape overview. And Git-enabled Change doesn’t support cCTS scenario so far. Create a Git-enabled Change (SMGH) with the Change Cycle you just created, set the status to “In Development“. As developer you have to assign a Git repository and branch to the Git-enabled Change, which means you code change will be managed by the Git repository you choosed. Normaly your gCTS system might be linked to several Git repositories, but you have to decide which one is used for your Change. After the Git Version Control Data saved, then you can start your development work with creating a new transport request. The gCTS transport request will be created by gCTS API and it has specific attributes assigned, although it looks the same like normal transport request but it will never be exported and imported (since there is not transport route at all). If the developer finishes the development work then next transport task should be released, during the releasing of the transport task the ABAP code will be pushed to related non-production branch (usually we use feature branch) of the Git repository. Go to Transport Management assignment block of your Git-enabled Change, there is a column named “Commits” in the table. Each time when developer releases a transport task from gCTS development system, the ABAP code will be pushed to Git repository with a new commit ID. Go to Transport Management assignment block of your Git-enabled Change, there is a column named “Commits” in the table. Each time when developer releases a transport task from gCTS development system, the ABAP code will be pushed to Git repository with a new commit ID. As developer finished the code change and set the Git-enabled Change to status “To Be Tested“, the code change will be pulled from Git repository and deployed into quality assurance system. During the whole process ChaRM triggered the code pull on quality assurance system, and the gCTS APIs on quality assurance system executed the pulling and delpoyment. This is totally different from traditional CTS mechanism, which original transport request or transport of copy was imported into quality assurance system. Go to Landscape assignment block of Git-enabled Change, there is column named “Current Commit” for each system, which means the newest code version comes from the commit of Git repository. The development system and test system now has the same current commit, so the ABAP code change already deployed into test system. This action will also be recorded in the text log. Click on the hyperlink of the commit ID, it will also open the commit details in Git repository. Till now developer handover the code change to tester and tester will verify the feature on test system, if everything works as expected then tester will set the Git-enabled Change status to “Successfully Tested“. The original gCTS transport request was released from development system, but it will never been exported because there is no consolidation route between development system and the test system, in gCTS world the releasing of the transport request only means the development work is completed, no new transport tasks and no commits will come. At this point of time, the testing phase is also finished. The Change Manager is considering making the code change productive, this means the Change Manager will approve the code change to be move into production system. To achieve this, the Change Manager set the Git-enabled Change to status “Authorized for Production“. And what ChaRM will do in the backend is very different from the past, since now ChaRM leverages the gCTS API and Git process, so if ABAP code is going to be productive, the code in Git repository must be productive first. This step will triggers an action in Git side: a Pull Request will be created and the approved, then the code in non-productive branch (feature branch) will be merged into production branch (master/main branch), this is how code change go-live in Git world. The production system is linked to the productive branch of the Git repository, so ChaRM has to make sure the code in Git side go-live first. The text log will record the action, and the Pull Request could be found in the Git. At the very last step it’s time to let the ABAP code go-live in the production system, IT Operator sets the Git-enabled Change status to “Deployed into Production“, then the code change will be pulled from productive branch (master/main branch) of the Git repository and deployed into production system. It is very similar when the code was deployed into test system, the only difference is that the code was pulled from non-productive branch (feature branch). Go to Transport Management assignment block, click on the icon in “Deploy Status” column, you will get an overview on which commit was deployed by which transport request for each target system and production system.