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.
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:
- Make assumptions regarding the target system state, look at the git history to find the limited list of objects to import
- Import all objects in the package every time
- 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 🙂
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.
It really doesn't work without open source 🙂 How about if abapGit as open source is installed directly with every SAP NetWeaver installation? No discussion with system owners because it's a standard part of their system?
I dont see it as an option, abapGit must be flexible
In a scenario where abapGit would be part of the installation, I guess it must be part of SAP namespace, which makes it really difficult to update it if updates are provided at all.
I agree.
What I really would love to see though is abapGit as a plug-in for Eclipse, so you could use it from the context menu like you do in Java-Projects.
there is vscode integration, https://marketplace.visualstudio.com/items?itemName=murbani.vscode-abap-remote-fs
and also an Eclipse plugin, however it does not work from the context menu
Thanks, I'd love to use Visual Studio (many thanks to Marcello Urbani in this context) but I will not be able to convince the responsibles in my company to allow access to the dev system with VS.
To achieve this with Eclipse was quite a discussion and was only successful because it is officially embraced by SAP.
A problem most of us will know: Managers who have no idea of technology.
Can you explain what you mean by 'Eclipse login' ?
vscode: it uses the same backend calls as ADT, so :shrug:, if you can use eclipse then its also technically possible to use the vscode plugin.
Generally, in my opinion, its up to the developer to choose the preferred tooling, and technology should give possibilities to choose
login: meant "plugin" sorry, updated, its linked from https://tools.hana.ondemand.com/#abap under "abapGit Plugin for ABAP Development Tools", and there is also https://github.com/abapGit/ADT_Backend
In the core there is already gCTS, at least for a system based on SAP_BASIS 7.54 SP00 or newer. So if we get the serialization in the git repositories synced there is hope for direct git support.
Interesting. Will keep an eye on this. Thanks!
In my view abapGit and CTS are complementary tools not alternatives.
Good writing 🙂
Best regards
Dominik Tylczynski
yea, there are a lot of pros and cons, hope that my braindump above give a few insights on when to use what 🙂
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
yea, handing dependencies is a super interesting topic, sometime in another blog post.... 🙂
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.
I think this is the way to go, given the current limitations of CTS:
J.
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
Mirroring transports is a great idea and easy to implement too, git push into a <SID> branch after import.