gCTS is still here

[Karin]

You might have missed news about gCTS when SAP S/4HANA 2022 was published. Maybe you even thought: is it already gone again?
Well, it is not. It is alive. There were just not that many spectacular new features available in the last release. This doesn’t mean that we stopped developing or that we do not enhance gCTS anymore.
In SAP S/4HANA 2023 we have some interesting new features that we hope you find useful.
In this blog post, you can get an idea of the biggest news – but there are also many smaller improvements. For the complete list and links to detailed documentation, please take a look at Git-Enabled Change and Transport System in the What’s New Viewer for ABAP Platform.
And don’t forget to take a look into SAP Note 2821718 - Central Note for Git-enabled Change and Transport System (gCTS) for updates and required other SAP Notes.
So now, finally, here are the bigger news for gCTS in SAP S/4HANA 2023:

• Tags: You can now tag commits and thereby mark them as ‘to-be-used’ commits. You can use any text for a commit, but if you used semantic versioning for them, you might find that more beneficial. If you used semantic versioning, the tag will also be added to the properties file of your repository. Meaning that a commit for this change to the properties file will be created. With this, you always know which commit contains the most recent ‘usable’ coding – so the one which is recommended for e.g., production systems as it contains a fully working and tested software state.
  
  Tags are managed on a separate tab, but are also shown on the Commits tab:
  


• Dependencies: It has been possible for a while to define dependencies between repositories. But this is now much easier. A graphical editor has been added. With this, you can easily oversee the dependencies that you have and whether they are fulfilled – so whether the required commits of depending repositories are available by the help of a simple color code. Tags are used here for current and expected versions. So, using tags is a must to be able to manage meaningful dependencies.
  


• Background Activities. If you need to pull a commit containing many changes or clone a ‘big’ repository, you might find it useful to do this outside of your working hours or maybe at least run that process without having to look at it. For this, you can now schedule background activities for cloning a repository, pulling a commit, or switching branches. You can either make it run immediately – but in the background - or define a certain date and time when you want the process to run. To plan the execution, you can find an arrow-down button next to the respective activity.
  
  Or you can plan it on the new Jobs tab. You can also delete a job there if it was planned for the future but is no longer needed
  


• Collaboration on Repositories
  Did you ever have the issue that someone is leaving your company? Maybe yes 😉. But what if he was the owner of a repository? You can now change the owner of a repository by assigning the appropriate permissions to someone else. In addition, it is now also possible (for GitHub and GitLab) to synchronize the user permissions from the Git provider to gCTS (not the other way round). To do so, it is a must that e-mail-addresses for users are maintained on both sides. User IDs can differ and are not taken into consideration for the synchronization. It is also possible to synchronize teams. In this case the team is created in gCTS and the users that also exist on the ABAP systems will be added to the team.
  

And – last but not least – we added new topics to the documentation to better explain the ‘g’ and the ‘CTS’ in ‘gCTS’. In References to Git Documentation we linked our documentation with the corresponding documentation of the required Git functionality . And in CTS Entities Used in gCTS you can learn more about how the entities of CTS that you might know from the past are used in gCTS and what is different.

Thanks for reading. As always: your feedback and questions are more than welcome!

[pepl]

Hi Karin, thank you for updates! I have asked this in your original post from 2019, but also commenting here just for the context. Do you have any plans to make gCTS part of ABAP Cloud environment?

Ideally what I would like to achieve is something like this:

1. SDK allowing to generate files in a local environment , but this should be the code capable to work in any place, like linux container, not ABAP system


2. Generated code must be in a format supported by both BTP and on-prem ABAP platform without any custom/community project dependencies ( to be subject of the vendor support )


3. There must be devops tool like gcts deploy allowing us to push the code to a target system from the local environment

Having these three things available it may create endless capabilities. One of them for example this CAP or RAP discussion. Imagine we have a tooling allowing us to create a model using CAP CDS, but then by some reason we decided to go RAP. What if we do something like this:

• cds bind --to abap which binds our service to abap instance


• cds compile --to abap which generates us ready-to-use ABAP service with tables, CDS views, RAP definitions, class templates and extensibility cabalities on the platform side


• cds deploy --to abap  which triggers the deployment script pushing current version to a target environment


• gctsDeploy allows us to trigger deployment for a git-based project but in case if it's a artifacts-based code, generated from the source files ( CAP, openapi, asyncapi) and existing only in runtime, we need to have something like ADT, but possible to be used without extensive knowledge on those formats

 

Do you think what I propose makes sense?

This approach may enforce more developers to create ABAP content and push it to platforms of their choice in an official way. abapGit is a great project but I guess SAP went gCTS way on purpose - so I just want to understand what is your vision for the future for this .

I'm open for any possible feedback meetings too if that matters. Looking forward to hearing from you.

Thank you!

Petr

[pepl]

vobu sebastian.schmidt5 that's what I meant, imagine we'll able to build such a system where both  stacks could be equally available for deployment, Hana or ABAP. Both presented on BTP. ABAP cloud has it's own benefits, so why wouldn't use this opportunity to onobard abap devs onto CAP without changing the stack ( like we actually did for Hana devs, generating Hana views and tables )

Another apporach is to generate abap-managed HDI container + Odata service ( supported by BTP according to documentation https://help.sap.com/docs/abap-cloud/abap-hana-tools-user-guide/version-2-96?q=%20ABAP-managed%20HDI... ). But in this case I'm afraid we will depend still on ABAP team by providing formats/endpoints to deploy artifacts from local environment into a target system ( like Eclipse does internally).

[pavupadhya]

Hi @Karin 

We are on S/4HANA On-prem 2022 FPS01. We have a requirement for auto deploying main branch from DEV to TEST system whenever the Unit Tests and ATC checks are successful. For this, we have configured GitHub actions on our repo and included gctsExecuteABAPQualityChecks and gCTSDeploy actions. When there is a commit to the main branch from DEV system, it automatically triggers the GitHub actions workflow to run both commands gctsExecuteABAPQualityChecks and gCTSDeploy and the action run is successful. 

However, in TEST system, main branch (Remote) is not updated to latest commit automatically, and hence the commit is not available in the local repo of TEST system. Kindly let us know what we are missing. 

Our sample config.yml is attached.  

Regards,

Pavithra

[Karin]

Hi Pavritha,
sorry for the late reply - I havfn't seen your question before.
Is there any log available on the Logs tab on the target system? Any activities?
Or maybe something in the results of the pipeline that rollback had been executed? The step will still be ok if rollback is executed but there might be a reason named in the output why rollback was done.

Kind regards

Karin

[damovand]

Hello Karin,

I have a question from a customer asking what is the difference between the gCTS and cTMS.  I have found numerous blogs and some tutorials explaining gCTS and cTMS but nothing that compares the two. 

Could you please help me and our customers understand the difference between the two tools?

[Karin]

Hi,

cTMS is a service on BTP that lets you manage software deliverables between accounts of different environments (such as Cloud Foundry, ABAP, and Neo), by transporting them across various runtimes. This includes application artifacts as well as their respective application-specific content. It supports many content types: https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/supported-conten...

with gCTS, you can push ABAP coding to a Gt repository and pull it from there into other ABAP systems. It is mainly used in SAP S/4HANA private cloud and on-premise but also in BTP ABAP environment and for some scenarios in public cloud. But in every case, the idea is to use Git as the storage for your ABAP coding. It does not come with any option to set up landscapes.

cTMS is made to set up landscapes in the cloud and to transport the coding artifacts. 

Currently only BTP ABAP environment is integrated with cTMS to make use of transport landscapes.

Dos this help?

Kind regards
Karin

[Karin]

Hi,
sorry, me again... to avoid misunderstandings: the sentence 'Currently only BTP ABAP environment is integrated with cTMS to make use of transport landscapes.' is about ABAP systems and their integration in cTMS. cTMS does not support ABAP Development in SAP S/4HANA Cloud Public and Private edition or on-premise.

Kind regards

Karin