Technical Articles
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.
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.
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:
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)
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.
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.
Sadly I can't try it now but thanks for the tip
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)
Agreed. And you can add the central repo design above to the design issues
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
I hope you have also filed an incident and got a fix for it?
This was in an openSAP course, I raised it there and had feedback. Looked big enough to post a warning here too
Understand that. And your warning is still needed also today? So the root cause was not yet removed?
I hope not, but I don't have access to a gCTS system anymore