Skip to Content
Technical Articles

CTS is beautiful

Every now and then I’ve been asked if abapGit can be used to deploy software to production, while it might be technically possible I heavily discourage doing it.

abapGit and CTS

SAP Change and Transport System(CTS) is used in ABAP systems to deploy software between systems, I guess most ABAP developers are familiar with transactions like SE09 and STMS

abapGit is a git client for ABAP written in ABAP, it is open source, and developed by the community on GitHub. It has been around for ~5 years is in active development, and works with versions 702 and up.

Introduction

abapGit is meant for helping software development, not software deployment, the requirements for these two areas are very distinct:

Software Development

  • Agility
  • Speed
  • Flexibility

Software Delivery

  • Reliable
  • Stable
  • Auditable

In software development, one developer might choose to switch from emacs to vim, this should not impact software delivery. A lot has happened in version control software, CVS has moved to SVN, SVN has moved to git, and git will move to something else sometime.

However, in the normal world(outside ABAP), the software delivery method has typically stayed the same with distributing executable/compiled files.

  • Maven is used for Java development
  • NPM is used for Javascript
  • And Crates for Rust

A lot of things break during software development, but it is not good to have errors during software delivery, as it can possibly impact production systems and users.

Parallel Development

Having ABAP code in git does not enable parallel development.

ABAP systems have one active version of a program, and abapGit works on package level, ie. it’s possible to have one branch checked out at a time. Developer1 can work on feature1, but developer2 cannot work on feature2 if it’s the same package, in the same system.

Some features might be added in abapGit to have one branch checked out and commit to a different branch, but it will not be very transparent.

To have parallel development, multiple ABAP systems/containers are required, as suggested by Ethan Jewett back in 2015.

Branching Strategy

In a typical 3 tier setup, DEV -> TST -> PRD, I don’t have an overview of how to do the branching properly. Assuming a setup with weekly fixed releases is quite easy, it will work with trunk based development.

But an agile setup where every feature can move through git and the environments gives more complexity and a lot of CI runs. I assume some manual testing will happen in TST, so some changes might be 1 hour on the way to production, and some might take months.

It feels like it would end up with the same as STMS, a list of branches for each system that has not been merged to that system/branch yet, with similar pitfalls as CTS.

Each traditional CTS transport can be seen as a “mini” branch for the objects that it contains, which is automatically rebased when imported to the target system. It would also be possible to put every object in its own package to simulate this behavior in git, but it would be a lot of work and not help developers.

Performance

abapGit works on package level, CTS on the objects that is part of the transport. If doing software delivery with abapGit I see the following three possibilities:

  1. Make assumptions regarding the target system state, look at the git history to find the limited list of objects to import
  2. Import all objects in the package every time
  3. Compare all objects in git vs the system and import everything that does not match

Making assumptions regarding ABAP system state is not something I’d recommend, everything can happen in ABAP πŸ™‚ It would also go against the reliability requirement for software deployment listed in the beginning.

abapGit is slower than CTS, and say the package contains 10k objects, and aiming to have an “agile” setup with changes constantly moved to production, I’m afraid this would end up in a deadlock situation where features cannot be imported because the previous imports are still running.

CTS on the other hand, works on object level, so if a developer changes a single report, only that report is part of the transport, making it the fastest import setup possible.

Rollback

With git it’s easier to do rollback, yes, especially during development on a feature branch, as it would typically not have any consequences.

Rolling back changes to production is more difficult, assuming it’s not the latest commit. Say, three unrelated changes, feature1 + feature2 + feature3 have been deployed successfully, and after a while a logical error is found in feature1, with git the rollback would cascade to feature2 and feature3, assuming it’s in the same package.
And before doing the rollback it must be manually analyzed if all 3 features can be rolled back, in case of DDIC changes.

Many customer custom developments are decoupled, consisting of small individual programs in a big package. With CTS it is possible to create a new transport rolling back feature1, not having to consider feature2 and feature3, there are also partner solutions that can do this automatically.

Stability

During my last 15 years of using CTS for ABAP deployment, I don’t recall having experienced a bug in CTS. Having bugs in the software deployment software, possibly causing requirements to upgrade to the latest S/4 HANA would be bad, software deployment needs stability.

Software development, on the other hand, needs agility, the possibility for new tools and processes. Hence abapGit can be upgraded without impact on the landscape, across a wide range of versions(702+), assuming it’s used for software development and not deployment.

Keeping the core clean

I see CTS as part of the core, it’s a prerequisite for running an ABAP installation. CTS is a good example of keeping the core clean and stable.

abapGit on the other hand is an option, with rapid development and changes, and should not be part of the core.

CTS could provide an API, so that new innovations can be built outside the core, utilizing the API. Integrations and APIs are also very important in the lower levels of the technology stack.

 

I’m not a git or CTS expert, so comments and corrections are welcome πŸ™‚

21 Comments
You must be Logged on to comment or reply to a post.
  • Great blog and important topic!

    Most systems I have to work with are managed by a Solution Manager. So I have to manage a lot of things about my transports there. Example: If I want to transport from development system to test system, I have to trigger that in Solution Manager. Some people find that very annoying and boring. But there are, at least for the system owner, some positive effects because of the better control what happens in CTS. If not anyone can do what he wants there is a need to better organize with the team πŸ˜‰ So abapGit would bring much freedom if you could use it in productive system – with alle positive and negative effects.

    Therefore the system landscapes I know have, in the best case, abapGit in development system installed and it’s used to import objects from other development systems or open source projects. After that, transports via CTS are needed to bring the objects to test and productive systems.

    By the way: In my experience, the installation of abapGit in a system must be approved by the system owner. This can also raise one or the other legal question and clarification can take a while.

    What are your experiences?

     

     

    • Good comment Michael.

      “So abapGit would bring much freedom if you could use it in productive system – with alle positive and negative effects”. That is surely a warning, if you want to keep your ERP production systems stable!

      Surely abapgit lends itself more to managing ABAP code across different SAP landscapes within the enterprise?

      CTS will never be replaced for production imports.

      • Yeah, the story will be something like “one fateful night a single developer made a very lonelyΒ  decision…” πŸ˜‰ Am I the only one with sometimes palpitations when pushing the import button in productive systems? There are moments I could talk about for a while. Last time was when Germany decided to change from 19% to 16%. That’s was a more than interesting night…

    • Solution Manager: yea, keeping track of changes is a topic of its own πŸ™‚

      Approval: It’s a good thing to keep systems under control, there are a few hints at https://docs.abapgit.org/#security which can be used in connection with an approval request.

      But we work in the software industry, things should move fast, and all modern companies use open source somewhere in the landscape, using open source in the ABAP system _should_ not be a problem.

       

  • I completely agree.

    And would add one more selling point about CTS based delivery: cross project coordination.

    ABAP systems share a single code base, regardless of package boundaries.

    If I ran my tests with version X ofΒ  package1 and version Y of package2, there’s no guarantee that package1 will work (or even import correctly) with a different version of package2

     

    CTS allows me to import both packages at the same time, git doesn’t

  • Thanks for the write up Lars Hvam . It’s a good read. I have sparingly “tried” and not “productively” used ABAPGit. My opinion is that it is good for distributing code / managing code across different systems using the push / pull means, not necessarily setting up a DEV->QA->PRD transport process. You are right that ABAPGit works primarily at a package level but when I did set-up something to test, I installed ABAPGit on my SAP system, developed some code, was able to export it to GitHUB and then every incremental code that I wrote, I was able to push that to GITHUB and it was incremental. I even tried using GITHUB desktop version and found the same result. So let’s say I move this code to a new system (pull from the new system) and the package doesn’t exist, it would definitely create everything from scratch. Once the main package and it’s contents are moved into the new system, all the subsequent actions will be delta isn’t it? This is my pure assumption. So whether I use CTS or ABAPGit, when it comes to importing or pulling contents into target goes, I would expect same runtime and outcome. But the best case as what little interaction I had with ABAPGit and use case that I have thought about is what Michael Keller mentioned. Use it in DEV but then go with CTS when it comes to actually setting up the DEV->QA->PRD transport process.

  • Great blog!

    As to how to integrate Git into a CTS landscape, there is no real answer. With CTS alone I’ve seen many different constellations, from simple DEV > PRD, to complex 7 system scenarios. Companies Β have all kinds of setups with hotfix systems and retrofits, maintenance vs project paths, de/centralised, sandboxes and whatnot.

    Adding Git only multiplies the possibilities, so there is no “best” way, every customer is unique. I think it’s almost a topic for a book, let alone a blog.

    • yea, its a big topic, but I think there are many benefits to realize if doing some kind of mirroring transports into git. This will not give risk, just extra information