Skip to Content
Technical Articles
Author's profile photo Marcello Urbani

Synchronization issues in gCTS

I just finished the opensap course DevOps for ABAP with gCTS in SAP S/4HANA

Lots of excellent content like advice on dockerization and hands-on experience with gCTS

And some confusing advice on branch switching on shared dev systems (which I find almost impossible to reconcile with a sane git based workflow.

One of the exercises though gave an unexpected result, as gCTS tells me my system is up to date with the latest commit on github:

…but the source code doesn’t match:

It might depend on me doing something wrong, but it’s not obvious what, and I already tried to update to the latest commit multiple times

I don’t have access to the system anymore, I was late with my exercises, but this is really scary.

I suspect this has to do with the synchronization between the local repository and the code in DEV

As I understand, gCTS has a copy of the code in a server folder, and syncs it both with the git repository and the ABAP server. I suspect there’s some bug in the last step.

Assigned Tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Mike Pokraka
      Mike Pokraka

      Like you, I really liked some of the content, but was severely put off by some of the 'features'. If I didn't know better I'd think that SAP are trying to reclaim their Special Snowflake status.

      For example: in the regular IT world comparing something with an older version, it will label new content as "added" or "+". On planet gCTS it is labeled as "deleted". When I queried this, I was told it's a point of view.

      And the other thing that irked me was that lots of stuff needs to be programmed in BADIs.

      Then we have the concept of a central registry to manage decentralised content. Huh? In the Git world the repository determines content.

      Special Snowflake indeed.

      Author's profile photo Marcello Urbani
      Marcello Urbani
      Blog Post Author

      Then we have the concept of a central registry to manage decentralised content. Huh? In the Git world the repository determines content.

      I think that's the root cause, and a questionable design decision.

      As the git repo is not the source tree, any update should basically do 2 operations:

      • update the git repository
      • update the source code in the ABAP system

      And since both can fail keeping them in sync requires a lot of bookkeeping with a single dev system. Much more (and repo locking) with multiple dev systems.

      The abapgit approach of serializing on the fly and implementing git in ABAP is inherently more robust (and slower)

      Author's profile photo Mike Pokraka
      Mike Pokraka

      Yes, it would make more sense to me that the Git repo should contain the object metadata (registry). It blows a huge hole into distributed development concept if you need access to a central registry.

      But as Lars said, it is clearly deployment-focused.

      I also don't like that it is a transport that defines the registry content. It means when I customise something new I need to maintain the registry again. I miss a more generic rule-based approach like all customising for foobar type ZX* go into repo A and ZY* goes into repo B.

      Author's profile photo Peter Inotai
      Peter Inotai

      Unfortunately I don't have access to the opensap demo system either, but I remember I had similar situation for one of the exercise. I had to trigger a Push manually from the Objects tab and it solved the problem.

      Author's profile photo Marcello Urbani
      Marcello Urbani

      Sadly I can't try it now but thanks for the tip

      Author's profile photo Lars Hvam
      Lars Hvam

      well, git is meant for development, and meant for _distributed_ development, trying to push it into a centralized setup will fail

      gCTS is for deployment, where synchronization issues can be fatal to businesses

      The goals for deployment are much different than development, see https://blogs.sap.com/2020/11/05/cts-is-beautiful/

      and by design, gCTS does not synchronize, it moves deltas based on assumptions(and we all know not to make assumptions in ABAP systems)

      Author's profile photo Marcello Urbani
      Marcello Urbani
      Blog Post Author

      Agreed. And you can add the central repo design above to the design issues

      Author's profile photo Marcello Urbani
      Marcello Urbani
      Blog Post Author

      Took me a while to digest your critique, but I think I get it and agree now.

      ABAP development is broken, deployment is fine.

      So gCTS primarily addressing deployment is a questionable decision.

      I do see value in scriptable deployments and the possibility to undo them (well, partially, as if you screw the data you can only recover it from a backup).

      We do  it  with transports already, but I can see a git based environment getting more reliable at those eventually. Definitely not now