On 24th November, I tried to explain and show the Git-enabled Change and Transport System (gCTS) in the SAP Community call ‘
Introduction to Git-enabled CTS’. Many questions remained open when time was over. Let me try to answer them in this blog post. I tried to summarize similar questions – so it might be that you cannot find exactly your question but hopefully all the topics are covered. If not, please use the comments for this blog post to ask your question.
Q: Why should we go for GitHub and all this stuff for ABAP in a normal 3 System Landscape?
A: There is maybe no reason to use gCTS in a pure ABAP environment. Classical CTS is available, and it will stay available. If you are happy with the process and flows that you use in CTS, continue using them! gCTS is made for cases, where CI / CD processes in a DevOps minded environment are needed for ABAP as well. gCTS is somehow the door opener for ABAP development into this world. With gCTS, it is e.g. possible to set up pipelines for ABAP development.
Q: gCTS only for SAP S/4 HANA possible? Not for ERP ECC? is there anything similar to gCTS available or planned for SAP ECC?
A: Currently, there are no plans to downport gCTS to anything below SAP S/4HANA 1909. For some parts, this is even not possible at all from a technical perspective.
Q: Is the strategy in the future is to replace the old STMS (as all the existing features are planned for gCTS ?)
A: There are no plans to replace CTS / STMS.
Q: Can we mix old STMS concepts and gCTS for deployment? Is it possible to have the classical CTS and gCTS to be running in a parallel? How can we choose which released transports go to git, and which go through the classical CTS path?
A: Yes, you can use classical CTS and gCTS in parallel for one system landscape. The transport layer determines which way a certain object goes. But you should decide once how a certain object is handled and not switch from classical CTS to gCTS and back and forth at every change of the object.
After a transport had been released, you cannot switch from one tool to the other anymore. What you can do is adding objects of a certain transport request to a repository. With this, you don’t have to change every object that you would like to handle via gCTS to add it to a new transport request. This is helpful to initially fill your repository with the objects that should not use classical CTS in the future anymore. Additional information is available on the SAP Help Portal in the topic
Manually Push Objects
Q: How does gCTS work with ChaRM (Change Request Management of SAP Solution Manager) and Focused Build.
A: First steps for an integration of gCTS into ChaRM are planned for the next SP of SAP Solution Manager 7.2. When this is published, we will also provide documentation explaining the details how this works in combination with STMS and classical CTS. Integration in Focused Build is not planned yet. How gCTS in ChaRM will work with CSOL and DGP is currently in some kind of planning phase. It might even be that some of the functionality is not needed if gCTS is in use. Transport requests are no longer the single source of truth for your ABAP objects. The coding to be imported is determined by the commit that you choose. Older or newer versions are not overwritten in the git repository. They are just part of another commit that is maybe currently not active in your ABAP runtime.
You can also get more details in the TechEd session
Change Control Management: Building a Bridge for CI/CD in a Hybrid Solution [DEV104]
Q: How to enable gCTS when we have a pure backend for all ABAP objects when we have different frontend system for Fiori?
A: The recommendation is to use the embedded Fiori. Carola Steinmeier describes that in her blog post
SAP Fiori Deployment Options and Recommendations. There is also a blog post available written by Jorge Baltazar
SAP Fiori for SAP S/4HANA – Transition from Standalone to Embedded Deployment in SAP S/4HANA to learn how to move from standalone to embedded deployment.
If you still decide to use the hub deployment, from a gCTS perspective, you need to activate the cts_abapvcs and the bc_cts_git services in the SICF transaction, and add the SAP Fiori Tile Catalog SAP_BASIS_TCR_T (SAP: Application Services) to the user roles that will use the gCTS app.
Q: see http in the URL (right, port 50008), not http(s) this right?
A: gCTS uses https (SSL) for sure. SSH is also possible. Http in the demo was only due to a special internal demo environment that I used. More details are described on the SAP Help Portal in the topic
Repository-Specific Authentication Options:
Q: Is the UI that we saw an officially released app?
A: The official App is the application called Git-enabled CTS which is available in the SAP: Application Services catalog. In the demo, I used a special version that is not published. But the difference is only that I had a system list on the left-hand side
Q: Is this part of the Trial Account
A: In SAP Cloud Platform, ABAP Environment, the Software Component App which uses gCTS in the background is part of the trial. Other features of gCTS are not available in SAP Cloud Platform, ABAP Environment.
Q: How would you setup a single git repository, where different branches should be deployed to different S/4HANA environments? We assume a scenario where we are providing a standardized product/service to multiple different clients, make a new version of the product and want to roll it out to our clients.
A: One branch is active for a certain system. What is provided in this branch can be imported into the ABAP runtime by using the functionality on the Commits-tab. It is always possible to switch branches and if you do so, the coding of the selected branch will be imported into the respective ABAP runtime. All the branches that exist for one repository are visible in the gCTS App in each system that is connected to the repository.
Q: Can gCTS also be integrated in Azure DevOps?
A: In principal, yes. We plan to publish the required API. The steps provided in Project ‘Piper’ do not completely depend on Jenkins. Please check the documentation in project ‘Piper’ to get the details what can be done in Jenkins only and what is possible outside – like e.g. for the step
gctsExecuteABAPUnitTests
Q Is Jenkins mandatory for the rollback feature?
A: We have a special step in Project ‘Piper’ that is made to add a rollback to a pipeline:
gctsRollback. But the functionality behind the rollback is available via the gCTS App: you can pull any commit from the commits list on the Commits tab into the respective ABAP system. Doing so will update the objects in your ABAP runtime to the version that is part of the respective commit. Details are described on the SAP Help Portal in the topic
Use the Commits Tab of the gCTS App
Q: Is it possible to do a preliminary import with gCTS? I mean import a single change in production and not the entire release assign to a branch?
A: Updates to an ABAP system are done on commit level. In the standard, a commit is created whenever you release a transport request. You can change that to creating commits when a task is released. This requires implementing a BAdI.
You can pull any commit into your ABAP system and thereby import the objects that are part of the commit. The differences between the commit that you chose and the commit that was active previously, are calculated and are imported.
If you switch the active branch in the gCTS App for a repository, then the latest commit is imported into the ABAP runtime.
You can influence the import behavior by setting parameters. Details are described on the SAP Help Portal in the topic
Update ABAP Target Systems
Q: Does gCTS work with all object types? Even objects that are classic "outdated" ones (e.g. generated table maintenance views require entries in SAP tables like TVIMF along with the coding to work properly)?
A:The way how transport requests are used in the development process is the same for classical CTS and for gCTS: all objects that are touched are tracked in a task. When you release the task and the transport request, a new commit is created that contains the objects that are part of the respective transport request. Therefore, any object that can be part of a transport request can be part of a commit. (Note that for customizing objects, support for CDAT is not available up to now). The import is done again by the same tools (tp and R3trans). When you choose a commit to be pulled, a new transport request containing the differences between the status of the objects in the system and the commit that you chose is created and imported. Note all of this is valid for SAP S/4HANA on Premise. The situation for SAP Cloud Platform, ABAP Environment is different. In there, gCTS is used in the background when you work with the Software Components App. You cannot use gCTS in there directly to e.g. manually push objects to the repository. It is therefore not possible to get any objects into the system that are not allowed in SAP Cloud Platform, ABAP environment
Q: Where is the object serialization of objects done and how performant is it? I've worked with abapGit and serialization in abapGit is rather slow for developments with thousands of objects. Is this better in gCTS?
A: Serialization is done when the transport request is released. The transport tools have been enhanced to be able to do so. ABAPGit is an open source project and not owned by SAP. Therefore, we are not conducting any comparisons between the two tools.
Q: Are there any other instructions, than project PIPER, Wizard or Note, available for step-by-step how-to guide (possible by video) of how to setup gCTS to connect an S/4HANA environment to a git repository
A: The configuration required for gCTS is described on the SAP Help Portal. Creating repositories is described in the topic
Configuring Repositories. If you follow the topic and its sub-topics, that will guide you through the configuration. Video is not available up to know but we plan to enhance our documentation with some in the future.
Q: With every commit, we can push a TR or a task also, but can we push multiple TRs in one go?
A: Commits are created by default when you release a transport request. To create a commit when a task is released, you have to implement a BAdI. These are the options that we have. You cannot combine several transport requests in one commit. But – if this is the origin of the question – you don’t have to import each commit. Just import the latest commit and all the changes that were done in between, will be imported as well.
Q: How does gCTS handle changes of multiple developers in the same object? Does it support hunk selection or some similar mechanism? How does the overwriting of changes work if two/more developers work on same SAP object?
A: The mechanisms of the development workbench (SE80 or ADT) are not touched by gCTS. The functionality that an object can only be changed by one developer at a time remains in place. You can still change only the active version of the coding. The version of an object that is active when a transport request is released, will be committed. If an object is committed of which the coding before that respective change of that transport request was different from what is available in Git, then conflicts will come up, if the repository is configured accordingly. This is possible starting with SAP S/4 HANA 2020. Details are available on the SAP Help Portal in the topic
Resolve Conflicts.
Q: Do we have controls for overwriting risks when you merge the development in the branches? Or define critical objects? or manage retrofit? In other words: has Git some Change Control tools?
A: I can’t speak for what Git does in general. Starting with SAP S/4HANA 2020, gCTS comes with a conflict resolution UI that you can use to work on conflicts. This requires that you prepare your repository in the gCTS App by setting two parameters. If you don’t set them, changes might be overwritten. You can find more information on the SAP Help Portal in the topic
Resolve Conflicts and
Use the Conflict Resolution Editor. This should be used when you do merges and end up with conflicts – which is most probably the case when you do fixes to n object and would like add this fix to your feature development, as well.
Another aspect in here: you can see the list of commits in the gCTS App and you can activate any of these commits. Be aware that this might include loss of data if you switch back to older versions of the coding that cannot handle the data that had been created based on the newer version.
Q:How does the multiple package mapping works from on-premise to git rep?
A: In gCTS, a transport layer (to a virtual SID in STMS) is used to decide whether a package or some objects that are part of the package shall be sent to Git as a commit or whether the classical CTS and transport routes shall be used. You can use the same transport layer for many packages. A transport layer is assigned to a repository. So all objects that make use of the same transport layer will be part of the same repository in Git. If you need special conditions or cannot change the assignment of packages, another option would be to implement a BAdI to define what shall go to Git. The BAdI implementation is described in the blog post
Create a commit in Git when an ABAP task is released. The blog post focuses on how to create commits when releasing a task – but you define also conditions in there when this commit is created, and you can set them according to your needs.
Q: Have seen, you only releasing the Tasks not the TR. When finally to be moved to Prod, how it goes with out TR released
A: First of all, working on a task basis to create commits requires implementing a BAdI. The BAdI implementation is described in the blog post
Create a commit in Git when an ABAP task is released.
Without this, commits will only be created when a transport request is released. But also, with the BAdI implementation, an additional commit will be created when you release the transport request.
Anyhow – transport requests don’t follow the transport routes into the import queue of a system, anymore, if you use gCTS. One option to manage the deployment of new software into production could be to use two branches: one for development (and test) and one for production. After development is finished and has been tested successfully, you could initiate a merge of the development branch into the production branch. This would be done via a pull request in e.g. GitHub. And only after the Pull request is finally approved, new software can be imported into production as only then, all the new and changed objects are available in the branch that is active for production.
Q: Can you merge ABAP and non-ABAP (open SQL)
A: You can use a mono-repository – if this is the question. Otherwise, gCTS does not provide any new development tools. It makes use of the transport mechanisms and tools.
Q: Will ABAP parallel development be possible on ABAP Cloud?
A: gCTS in the way you saw it in the session is only available in SAP S/4HANA 1909 and 2020. SAP Cloud Platform uses gCTS for managing Software Components. But in there, you currently cannot work with the repository or with commits other than what is provided in the Software Components App.
In addition and in general: gCTS does not allow parallel development. The object locking mechanisms of the ABAP workbench are still in place
Q: Do you have any best practice for organization the new gCTS. cause in the "old" world sap basis guys are manage/setup CTS but now they should have knowledge about git, jenkins but this knowledge isn't in the SAP ABAP admin's mind
A There is no best practice for this. I think that this is a learning curve. Developers need to get into the mindset of the DevOps world and learn. Basic idea could be to start with a small project which is decoupled from the rest of your ABAP development and which can be used as playground. Use this to get some experiences with gCTS. You don’t need extra systems for that. gCTS can be used in parallel with classic CTS. A staring point could maybe also be page
Continuous Integration and Delivery by SAP on the SAP Help Portal to learn about CI/CD in general – not specifically for ABAP
I hope that I could clarify some questions. Feel free to comment on this blog post to start further discussions or ask additional questions
