Der Begriff DevOps wird in SAP-Kontexten überstrapaziert. Wer in einer DSAG-Arbeitsgruppe sitzt, hört unter dem Stichwort sehr verschiedene Dinge: Git-Versionierung von ABAP-Code, automatisierte ATC-Checks, Jenkins-Pipelines für SAPUI5, Cloud Transport Management, kontinuierliche Deployment-Workflows in der BTP, Continuous Compliance, Shift Left Security. All das ist nicht falsch, aber es ist auch nicht dasselbe.
Für einen Realitätscheck braucht es zuerst eine saubere Begriffsabgrenzung. SAP DevOps in der ABAP-Welt 2026 besteht aus mehreren technischen Bausteinen mit unterschiedlichem Reifegrad und unterschiedlicher Reichweite.
Versionierung: Der Quellcode wird in Git-Repositories gehalten, mit Branches, Pull Requests und Code Review. Die wichtigsten Werkzeuge sind abapGit (Community, MIT) und gCTS (Git-enabled CTS, SAP-Standard).
Build und Test-Automation: ATC-Checks, AUnit-Tests und Quality Gates laufen automatisch bei jedem Code-Change. Die wichtigsten Werkzeuge sind Project Piper Steps für Jenkins, GitHub Actions, das ABAP Test Cockpit selbst und SAP Code Inspector.
Pipeline-Orchestrierung: Eine CI/CD-Pipeline koordiniert die Schritte vom Commit über Build, Test bis zum Deployment. Hier sind Jenkins mit Project Piper Steps, GitHub Actions, Azure DevOps Pipelines, SAP Continuous Integration and Delivery service auf BTP und vendor-spezifische Pipelines (ReleaseOwl, ActiveControl, SmartChange) im Einsatz.
Transport und Deployment: Die Auslieferung der getesteten Änderungen an Q-Systeme und Produktion. Hier konkurrieren das klassische CTS, das CTS+ Erweiterungssystem, gCTS, Cloud Transport Management Service (cTMS), Project Piper-Steps für Transports und externe Werkzeuge wie SolMan ChaRM oder Cloud ALM Change Management.
Operations und Monitoring: Alerts, Drift Detection, Audit Trails. Hier dominieren SAP Cloud ALM, SAP Solution Manager Focused Run, Datadog, Splunk und Eigenentwicklungen.
DevOps ist kein Bypass des Change Managements. Wer das so versteht, hat das Modell missverstanden. Die SAP-Hinweis-11599-Realität bleibt: Transports, die in Produktion ankommen, sind irreversibel im klassischen Sinn. CI/CD-Pipelines verschnellern den Pfad bis zur Produktion, sie ersetzen nicht die fachliche Genehmigung dort. Das verlangt EU AI Act Article 14 (Human Oversight) für AI-gestützte Pipelines, das verlangen SOX und DORA für Finanz-Workflows, das verlangt jeder Hersteller, der ATC nicht ausreicht. Der vorliegende Artikel betrachtet daher CI/CD-Patterns immer im Kontext von Governance.
Drei parallele Entwicklungen verändern die SAP-DevOps-Landschaft 2026 fundamental.
Erstens wird die SAP-eigene CI/CD-Hauptbibliothek Project Piper am 31. Dezember 2026 eingestellt. Auf der Repository-Seite github.com/SAP/jenkins-library steht offiziell: "No further updates, bug fixes, or pull requests will be accepted after December 31, 2026". Das Schwester-Repository github.com/SAP/project-piper-action wurde am 7. April 2026 archiviert. Damit verliert der seit 2018 als Empfehlung etablierte Pfad für SAP-CI/CD seine Wartung.
Zweitens hat sich gCTS als Standard etabliert, aber mit harten Grenzen. SAP-Hinweis-Implementierungen, Modification Adjustments nach Support Package Imports und cCTS-Szenarien fallen aus dem gCTS-Pfad heraus. Für diese Fälle bleibt die klassische CTS-Konfiguration Pflicht, oft im Mix-Mode mit ChaRM.
Drittens ist die Adoption deutlich niedriger als die Marketing-Sprache vermuten lässt. Der DSAG-Investitionsreport 2026 zeigt: Nur ein Bruchteil der Unternehmen hat produktive ABAP-CI/CD-Pipelines. Die meisten Mittel- und Großunternehmen in DACH arbeiten weiterhin im klassischen CTS-plus-ChaRM-Modus, oft mit hohen manuellen Anteilen.
Das Change and Transport System (CTS) ist seit den 1990er Jahren Bestandteil von SAP-Systemen. Es transportiert ABAP-Objekte und Customizing in einer dreistufigen Landschaft (DEV, QAS, PRD) über Co- und Daten-Dateien im Transportverzeichnis (typisch /usr/sap/trans). Die Konfiguration läuft über die Transaktion STMS, Transport-Routen werden zentral im Domain-Controller-System verwaltet.
CTS+ ist die Erweiterung des klassischen CTS für nicht-ABAP-Inhalte (etwa SAP NetWeaver Portal, SAP Process Integration, SAP HANA-Modelle). Es nutzt dieselbe Transport-Infrastruktur, aber mit zusätzlichen Adaptern.
Stand 2026: CTS und CTS+ sind weiterhin der Standard für die meisten SAP-On-Premise-Landschaften. Die DSAG-Investitionserhebung 2026 zeigt, dass über 56 Prozent der DACH-Unternehmen S/4HANA-On-Premise oder Private-Cloud betreiben. Für diese Landschaften ist CTS die produktive Realität, nicht eine veraltete Option.
Mit S/4HANA 1909 hat SAP gCTS eingeführt, ab S/4HANA 2020 ist der volle Funktionsumfang verfügbar. gCTS speichert ABAP-Transports nicht mehr nur als Co/Daten-Dateien im Transportverzeichnis, sondern serialisiert sie in ein verbundenes Git-Repository (GitHub, GitLab, Bitbucket, Azure DevOps).
Voraussetzungen Stand 2026: S/4HANA 2025 erfordert Open JDK 17 oder SAP Machine 21 (LTS), ältere Java-Versionen funktionieren nicht mehr. Credentials sind seit S/4HANA 2025 mandantenspezifisch. ChaRM-Integration mit gCTS funktioniert nur mit GitHub als Git-Server, andere Git-Provider haben Einschränkungen. gCTS unterstützt keine cCTS-Szenarien (Cloud CTS für Multi-Tenant-Setups).
Was nicht über gCTS läuft: SAP-Hinweis-Implementierungen und Modification Adjustment Transports nach Support Package Imports können nicht in Git-Repositories gepusht werden. Für diese Fälle bleibt die klassische CTS-Konfiguration zwingend nötig. ChaRM-Anwender müssen den Mix-Mode aktivieren, um Custom-Code über gCTS und Customizing über klassisches CTS parallel zu transportieren.
abapGit ist ein in ABAP geschriebener Git-Client, der seit etwa 2014 von Lars Hvam entwickelt und seitdem von einer aktiven Community gepflegt wird. Er steht unter MIT-Lizenz und ist auf github.com/abapGit/abapGit verfügbar. Die Installation erfolgt über einen einzelnen Standalone-Report (zabapgit_standalone.abap), der direkt in das System eingespielt wird, oder über ein ADT-Plugin für Eclipse.
abapGit ist primär ein Versionierungs- und Migrations-Werkzeug, keine Enterprise-CI/CD-Plattform. Es transportiert keine Customizing-Tabellen, hat keine integrierte Pipeline-Orchestrierung, kein Quality-Gate-Konzept, keine Rollback-Logik auf Landschafts-Ebene. Der typische produktive Einsatz: Backup eigener Z-Entwicklungen, Code-Sharing zwischen Entwicklern, Migration von On-Premise-Code in BTP-ABAP-Environment, Open-Source-Projekt-Distribution.
Das Community-Statement vom Februar 2026 (abapcloud.com): "abapGit for developers, gCTS for enterprise CI/CD". Diese Differenzierung ist die ehrliche Bewertung. abapGit ist im Werkzeugkasten unverzichtbar, aber nicht der Träger eines Unternehmens-Pipelines.
Project Piper ist seit 2018 die SAP-Open-Source-Initiative, die wiederverwendbare Jenkins-Pipeline-Bausteine für SAP-Szenarien bereitstellt. Das Hauptrepository github.com/SAP/jenkins-library enthält über 200 Pipeline-Steps für Build, Test, Deployment, Transport und Quality Management.
Der Kernbefund Stand Mai 2026: Auf der GitHub-Repository-Seite des Projekts steht offiziell: "No further updates, bug fixes, or pull requests will be accepted after December 31, 2026". Das parallele Repository github.com/SAP/project-piper-action wurde am 7. April 2026 archiviert und ist read-only. Das alte Repository github.com/SAP/jenkins-pipelines wurde ebenfalls archiviert.
Folgen für Anwender: Bestehende Pipelines, die auf Project Piper aufbauen, funktionieren weiter. Sicherheits-Patches, Bug-Fixes und neue Features nach dem 31. Dezember 2026 wird es offiziell nicht mehr geben.
cTMS ist der BTP-native Transport-Service, der seit 2019 verfügbar und seit 2023 für BTP ABAP Environment integriert ist. Er ersetzt für Cloud-Workloads die klassische STMS-Konfiguration durch eine cloud-basierte Transport-Orchestrierung mit Web-UI, OAuth 2.0-API und Multi-Tenant-Unterstützung.
Funktionsumfang: Transport von Multi-Target-Application-Archiven (MTA), UI5-Apps, ABAP-Cloud-Objekten, SAP Integration Suite Content über mehrere BTP-Subaccounts hinweg. Audit-Trail-Logging mit Zeitstempel und User-Identität für Compliance-Nachweise. Quality-Gate-Konzept mit Approve/Reject-Workflows pro Transport-Knoten.
Beschränkungen: cTMS unterstützt keine Transports von BTP-ABAP-Inhalten über globale Accounts hinweg. Für reine On-Premise-S/4HANA-Landschaften ohne BTP-Komponenten bringt cTMS keinen direkten Mehrwert, hier bleibt das klassische CTS oder gCTS Standard.
Über 56 Prozent der DACH-Unternehmen betreiben S/4HANA On-Premise oder Private Cloud. Für diese Landschaften ist klassisches CTS plus optional ChaRM weiterhin das Standard-Setup. Die Migration zu gCTS oder zu BTP-basierten Transport-Modellen ist meist nur Teilbereich-bezogen (etwa für neue Fiori-Apps), nicht durchgängig.
Diese operative Realität wird in der Marketing-Kommunikation oft unterschätzt. Die typische Konfiguration ist immer noch: SE80 oder ADT für Entwicklung, SE09/SE10 für Transport-Anforderungen, STMS für Transport-Steuerung, ChaRM für Genehmigungs-Workflow, Excel-Export für das Compliance-Reporting.
gCTS hat in den letzten 24 Monaten an Verbreitung gewonnen, aber typischerweise nur in Teilbereichen. Häufiges Muster: Ein Innovations-Team hat einen gCTS-Pilot für eine neue Z-Komponente, der Rest der Landschaft läuft klassisch. Die volle Umstellung scheitert oft an der nicht-gCTS-fähigen Customizing-Welt und am ChaRM-Mix-Mode-Aufwand.
Der SAP CI/CD Service auf BTP und Project-Piper-Pipelines werden produktiv vor allem für reine BTP-Workloads genutzt: SAPUI5 und Fiori Apps, CAP-Anwendungen, Integration-Suite-iFlows, ABAP Environment (Steampunk). Für klassisches On-Premise-ABAP ist die BTP-CI/CD-Welt nur über Umwege erreichbar.
abapGit ist in vielen Unternehmen produktiv im Einsatz, aber als persönliches Werkzeug der Entwickler, nicht als zentrale CI/CD-Komponente. Typische Use Cases: Entwickler sichern eigene Z-Entwicklungen außerhalb des Unternehmens-Transport-Systems, Migration von Code zwischen Systemen, Backup vor Refactoring-Aktionen.
Werkzeuge wie ActiveControl (Basis Technologies), Rev-Trac, SmartChange (REALTECH) und ReleaseOwl bieten kommerzielle Alternativen zur SAP-eigenen DevOps-Werkzeug-Welt. Sie integrieren typischerweise CTS, gCTS, cTMS und Drittsystem-Workflows in einer einheitlichen Oberfläche.
Aus der Marktanalyse ergeben sich vier dominante Patterns für SAP-CI/CD im Frühjahr 2026. Jedes hat einen klar definierten Anwendungsbereich, Vor- und Nachteile, und einen Status hinsichtlich Zukunftssicherheit.
ABAP-Code wird in S/4HANA entwickelt, gCTS pusht in GitHub-Enterprise, Jenkins mit Project-Piper-Library ruft ATC-Checks, AUnit-Tests und Deployment-Schritte. Anwendungsbereich: SAP-Standard-empfohlener Pfad für moderne ABAP-Entwicklung. Vorteile: Native SAP-Integration, vollständige Pipeline-Steps verfügbar, Git-Versionierung mit Branch-Management. Nachteile: Project Piper läuft am 31. Dezember 2026 aus. Wer dieses Pattern in 2026 neu aufbaut, plant von Beginn an die Migration mit ein. Status: Auslaufend.
Entwickler nutzen abapGit zum Push und Pull gegen ein GitHub-Repository. GitHub Actions führt automatisierte Checks aus (etwa abaplint für statische Analyse, Custom-Skripte für ATC-Trigger via API). Deployment erfolgt manuell über abapGit-Pull oder über klassisches CTS. Anwendungsbereich: Teams mit hoher Eigenverantwortung und niedrigem Customizing-Anteil. Vorteile: Vollständig Open Source, keine Abhängigkeit von SAP-Lizenz-Modellen. Nachteile: Kein Customizing-Transport, keine native Quality-Gate-Logik auf Landschafts-Ebene, kein integriertes Rollback-Konzept. Status: Stabil als Nische.
Hybrid-Landschaften mit On-Premise-S/4HANA und BTP-Erweiterungen. CTS plus ChaRM für On-Premise, cTMS für BTP-Workloads, Cloud ALM als übergreifende Orchestrierungsschicht. Vorteile: Saubere Trennung der Welten, vollständige SAP-Integration, langfristige Roadmap-Sicherheit. Nachteile: Hohe Komplexität durch parallele Transport-Mechanismen, hoher Konfigurationsaufwand, Cloud-ALM-Abdeckung für ChaRM-Funktionen Stand 2026 noch unvollständig. Status: Wachsend und zukunftssicher, aber konzeptuell schwierig zu beherrschen.
Klassisches CTS bleibt das Rückgrat, ChaRM steuert den Genehmigungs-Workflow, ATC-Checks laufen automatisiert über zeitgesteuerte Jobs (typisch SM37) oder über externe Werkzeuge. Anwendungsbereich: Über die Hälfte der DACH-Unternehmen nach DSAG-Investitionsreport 2026. Vorteile: Etabliert, stabil, vollständig SAP-supported, alle Customizing- und Modification-Adjustment-Szenarien abgedeckt. Nachteile: Keine Git-Versionierung von ABAP-Code als Teil des Standard-Workflows, manuelle Schritte dominieren, langsame Feedback-Zyklen. Status: Solider Status quo, aber unter Druck.
| Pattern | Customizing | ABAP-Code | Quality-Gate | Compliance-Tauglich | Zukunftssicher |
|---|---|---|---|---|---|
| A: gCTS plus Project Piper | Mix-Mode nötig | Native | Pull-Request | Ja | Auslaufend (Piper EoL) |
| B: abapGit plus GitHub Actions | Nicht abgedeckt | Native | GitHub-PR | Eingeschränkt | Stabil als Nische |
| C: Hybrid mit Cloud ALM und cTMS | CTS On-Prem | gCTS On-Prem, cTMS BTP | CALM-orchestriert | Ja | Wachsend |
| D: Klassisch CTS plus ChaRM | Native | CTS-Versionierung | ChaRM-Genehmigung | Ja | Solider Status quo |
In den vier Patterns kommen unterschiedliche Werkzeuge zum Einsatz. Dieser Abschnitt bewertet die wichtigsten Anbieter nach sechs Kriterien: K1 Customizing-Abdeckung, K2 Git-Integration, K3 Pipeline-Orchestrierung, K4 Compliance-Logging, K5 Rollback-Fähigkeit, K6 Roadmap-Sicherheit.
Klassisches CTS und ChaRM: Das Standard-Setup für die meisten Bestandskunden. Stark in der Customizing-Abdeckung, schwach in der Git-Integration. Mainstream Maintenance des SolMan endet 2027, Extended Maintenance bis 2030 möglich.
gCTS: Der SAP-empfohlene Pfad für Git-basierte ABAP-Entwicklung. Reift seit 2020, jährliche Erweiterungen mit jeder S/4HANA-Major-Version. Funktioniert produktiv für Code-Transports, aber Customizing-Mix-Mode erforderlich. Bindung an GitHub für vollen ChaRM-Funktionsumfang.
abapGit: Das wichtigste Community-Werkzeug. Reife Codebasis seit 2014, mit aktiver Maintenance durch eine Community von etwa 30 regelmäßigen Contributoren. MIT-Lizenz, breite Git-Provider-Unterstützung. Stärke: Persönliche Versionierung und Cross-System-Migration. Schwäche: Kein Enterprise-CI/CD-Konzept.
cTMS: SAP-strategisches Cloud-Produkt für BTP-Transports. Aktive Weiterentwicklung durch SAP-Produkt-Team. Klare BTP-Fokussierung, eingeschränkte On-Premise-Relevanz.
Project Piper: Auslaufende Open-Source-Initiative mit klarem Ende am 31. Dezember 2026. Trotz Auslauf weiterhin der funktional vollständigste Open-Source-Pipeline-Bausteinkasten für SAP. Nutzung in 2026 sinnvoll für bestehende Pipelines, neue Pipelines sollten Migrations-Strategie vorsehen.
SAP CI/CD Service auf BTP: Das kommerzielle SAP-Angebot mit SLA. Nutzt aktuell Project Piper unter der Haube. Strategische Position nach 31. Dezember 2026 unklar. Kann als Zwischenlösung dienen.
ChaRM in SolMan 7.2: Das ETL-Tool des klassischen SAP-Change-Managements. Mainstream Maintenance bis Ende 2027. Migration zu Cloud ALM ist die offizielle SAP-Empfehlung, aber Cloud ALM hat 2026 noch Funktions-Lücken.
Cloud ALM Change Management: Strategisches SAP-Cloud-Produkt im Aufbau. Stand März 2026 fehlen mehrere ChaRM-Funktionen (etwa SoD-Checks, Custom Workflows). Roadmap zeigt schrittweise Annäherung bis 2028.
ActiveControl (Basis Technologies): Britischer Anbieter, seit über 20 Jahren am SAP-Markt. Stärke in der Backout-Funktion und in der Multi-Stream-Pipeline-Logik. Lizenz-Modell pro Landschaft, typisch im sechsstelligen Bereich für Großunternehmen.
Rev-Trac (Rev-Trac Inc., USA): US-Anbieter, ähnlich lange am Markt. Eigene Pipeline-Engine ohne klassisches Backout-Konzept (eigenes "OOPS"-Recovery-Konzept). Starke Integration mit ServiceNow und Jira.
SmartChange (REALTECH): Deutscher Anbieter aus Heidelberg, mit starker Verankerung im DACH-Mittelstand. Native Integration in cTMS und SolMan ChaRM. Lizenz-Modell flexibel skalierbar.
ReleaseOwl: Indischer Anbieter, jüngerer am Markt. Native gCTS-Integration, Pipeline-Bausteine für klassisches CTS und gCTS gleichermaßen. Wachsende Relevanz im DACH-Markt.
Das klassische Vier-Augen-Prinzip im SAP-Change-Management ist: Eine Person entwickelt, eine andere genehmigt vor Produktion. In modernen CI/CD-Pipelines wird das Vier-Augen-Prinzip oft durch Pull-Request-Reviews abgebildet: Der Entwickler erstellt einen Pull-Request, ein zweiter (oder dritter) Reviewer muss explizit "Approve" geben, bevor der Merge in den Main-Branch passiert. Das ist konzeptuell äquivalent, hat aber ein paar Fallstricke.
Erstens, Branch-Protection-Rules müssen sauber konfiguriert sein. Ein Repository ohne "Require Pull Request Reviews" Setting ist kein Vier-Augen-Setup. Zweitens, der Reviewer-Pool muss disjunkt vom Entwickler-Pool sein. Wenn der Entwickler in der Lage ist, sich selbst zu approven (etwa über einen zweiten Account), bricht das Prinzip. Drittens, der automatisierte Deployment-Schritt nach dem Merge darf nicht vor dem Reviewer-Approval ausgeführt werden.
Schnellere Pipelines bedeuten schnellere Wege zu Produktions-Bugs. Der vorhergehende COI-Artikel zu SAP-Hinweis 11599 hat sechs Recovery-Patterns für problematische Transports beschrieben. Diese Patterns sind unter CI/CD genauso anwendbar wie unter klassischem CTS, aber sie skalieren schlecht, wenn die Frequenz der Produktions-Deployments steigt.
In der Praxis hat sich folgendes Modell bewährt: CI/CD-Pipeline für DEV-zu-Q-System läuft in voller Geschwindigkeit, mit minimalen Quality-Gates. Q-System-zu-Produktion läuft mit Vier-Augen-Approval und automatisch erzeugtem Transport of Copies als Backup. Das ist langsamer als ein "Continuous Deployment to Production"-Pattern, aber risiko-adjustiert deutlich tragfähiger für SAP-Landschaften.
EU AI Act Article 12 (Logging-Pflicht für Hochrisiko-AI-Systeme), DORA (für Finanzdienstleister), NIS2 (für etwa 29.500 deutsche Unternehmen) und SOX verlangen alle ein strukturiertes Audit-Logging über Change-Aktionen. In modernen CI/CD-Pipelines muss das Audit-Logging mehrere Quellen integrieren: Git-Commit-History, Pull-Request-Metadaten, Pipeline-Run-Logs, ATC-Check-Ergebnisse, gCTS-Push/Pull-Events, cTMS-Transport-Logs, Deployment-Bestätigungen.
Während der Code-Erstellung in ADT: Live-ATC-Checks im Editor, abapGit-Commit-Hooks für statische Analyse, abaplint-Integration als Pre-Commit-Hook. Beim Pull-Request: Automatisierte ATC-Voll-Checks, AUnit-Test-Suite, Sicherheits-Scans, Berechtigungs-Check. Beim Deployment ins Q-System: Schreib-Sandbox-Test mit dedizierten Test-Daten, Performance-Regression-Tests, Integration-Tests mit anderen Modulen. Beim Deployment in Produktion: Vier-Augen-Approval, automatisches Backup (Transport of Copies), Smoke-Tests nach Deployment, Rollback-Bereitschaft.
Der SAP CI/CD Service auf BTP ist ein kommerzielles SAP-Angebot mit SLA, das viele Project-Piper-Funktionen abdeckt. Er nutzt unter der Haube selbst Project Piper, was die Frage offenlässt, wie SAP nach dem 31. Dezember 2026 die zugrundeliegende Library weiterentwickelt. Stand Mai 2026: SAP hat keine offizielle Roadmap für die Post-Piper-Strategie des CI/CD Services veröffentlicht.
Eine native Migration weg von Jenkins und Project Piper hin zu modernen CI/CD-Plattformen wie GitHub Actions oder Azure DevOps. Die SAP-spezifischen Pipeline-Steps müssen entweder neu implementiert werden (über die SAP-APIs für gCTS, cTMS, ATC) oder über Open-Source-Forks von Project Piper bezogen werden. Vorteile: Moderne Pipeline-Plattformen, breite Community-Unterstützung. Nachteile: Erheblicher Aufwand für die Neuentwicklung der SAP-spezifischen Steps.
Werkzeuge wie ActiveControl, Rev-Trac, SmartChange und ReleaseOwl bieten eigene Pipeline-Engines, die unabhängig von Project Piper funktionieren. Sie integrieren CTS, gCTS, cTMS und ChaRM in einer einheitlichen Oberfläche. Vorteile: Vendor-supported, langfristige Roadmap, breite Funktionsabdeckung. Nachteile: Lizenzkosten (typisch sechsstellige Beträge für Großunternehmen).
Project Piper ist Open Source unter Apache-2.0-Lizenz. Theoretisch kann die Community den Code forken und eigenverantwortlich weiterpflegen. Erste Initiativen sind im Frühjahr 2026 sichtbar, allerdings ohne klares Konzept einer langfristigen Maintainer-Struktur. Vorteile: Investitionsschutz für bestehende Pipelines. Nachteile: Keine offizielle SAP-Unterstützung mehr.
Phase 1 (Q3 2026): Inventarisierung aller Project-Piper-Pipelines im eigenen Unternehmen. Phase 2 (Q4 2026): Strategische Entscheidung pro Pipeline-Cluster. Phase 3 (Q1-Q2 2027): Migration der ersten Pilot-Pipelines auf den Ziel-Pfad. Phase 4 (ab Q3 2027): Skalierte Migration aller Pipelines. Diese Phasen-Aufteilung kostet mindestens 12 bis 18 Monate. Wer im Mai 2026 noch nicht angefangen hat, hat keine entspannten zwei Jahre vor sich. Die Empfehlung ist, das Thema spätestens Q3 2026 strategisch zu adressieren.
Customizing-Transports (Tabelle T030, Pflichtfelder, Buchungsregeln) und ABAP-Code-Transports (Klassen, Reports, FUGRs) haben unterschiedliche Lebenszyklen, unterschiedliche Test-Anforderungen und unterschiedliche Risiko-Profile. Empfehlung: Zwei getrennte Pipelines, mit unterschiedlichen Quality-Gates. Die Customizing-Pipeline läuft tendenziell langsamer, mit stärkerem fachlichem Review, weil Customizing-Fehler oft direkt buchungs- und damit finanz-relevant sind. Die ABAP-Code-Pipeline läuft schneller, mit stärker automatisierten Tests (AUnit, ATC).
Audit-Trails aus verschiedenen Quellen müssen aggregiert werden. Diese Aggregation darf nicht als Nebenfunktion einer einzelnen Pipeline behandelt werden, sondern muss eine eigenständige Architektur-Komponente sein. Empfehlung: Ein zentrales Compliance-Logging-System, das von allen Pipelines, allen Transport-Werkzeugen und allen Drittwerkzeugen mit Logs gefüttert wird.
SAP-Hinweis 11599 sagt klar: Transports sind nicht zurückrollbar im klassischen Sinn. Empfehlung: Vor jedem Produktions-Deployment wird automatisch ein Transport of Copies des aktuellen Zustands erstellt und in einer dedizierten Backup-Konfiguration gehalten. Bei Problemen mit dem Deployment kann der Transport of Copies relativ schnell re-importiert werden, was zumindest den letzten konsistenten Zustand wiederherstellt. Diese Empfehlung kostet etwas Zeit pro Deployment (typisch 1-3 Minuten) und etwas Speicherplatz im Transportverzeichnis. Beides ist trivial im Vergleich zu einem mehrstundigen Recovery-Aufwand bei einem Produktions-Problem ohne Backup.
Erste Kernaussage: SAP DevOps für ABAP ist 2026 keine homogene Welt, sondern ein Werkzeug-Mix aus klassischem CTS, gCTS, abapGit, Project Piper, cTMS und kommerziellen Drittwerkzeugen. Die Realität in der Mehrheit der DACH-Unternehmen ist klassisches CTS plus ChaRM, mit punktuellen DevOps-Inseln. Wer Marketing-Botschaften wie "alle SAP-Customer machen jetzt CI/CD" hört, sollte die DSAG-Investitionserhebung 2026 daneben legen.
Konkrete Handlungsempfehlung: Eine ehrliche Bestandsaufnahme der eigenen Pipeline-Architektur. Welche Patterns sind im Einsatz, welche Werkzeuge, welche Lücken? Ohne diese Bestandsaufnahme bleibt jede Strategie spekulativ.
Zweite Kernaussage: Project Piper läuft am 31. Dezember 2026 aus. Das ist der zentrale Realitäts-Faktor des Jahres 2026 für SAP-DevOps. Wer Pipelines auf Piper-Basis betreibt, hat ein definiertes Ende der offiziellen SAP-Wartung. Vier Migrations-Optionen stehen zur Verfügung: SAP CI/CD Service auf BTP, GitHub Actions oder Azure DevOps, kommerzielle Drittanbieter-Plattform, oder Community-Fork von Project Piper.
Konkrete Handlungsempfehlung: Bis Q3 2026 eine strategische Entscheidung pro Pipeline-Cluster. Bis Q1 2027 erste Pilot-Migrations. Bis Q3 2027 skalierte Migration. Wer diesen Zeitplan einhält, hat 2027 eine sichere Pipeline-Plattform.
Dritte Kernaussage: DevOps für SAP ist kein Bypass des Change Managements. Schnellere Pipelines bedeuten höhere Recovery-Anforderungen. SAP-Hinweis 11599 (Transport-Irreversibilität) bleibt unverändert relevant. Vier-Augen-Prinzip, Audit-Trail-Aggregation und automatisches Backup vor Produktions-Deployment sind drei Bausteine, die in jeder Architektur unabhängig vom gewählten Pattern adressiert werden müssen.
Konkrete Handlungsempfehlung: Pre-Deployment-Backup-Mechanismen über alle Pipelines hinweg standardisieren. Audit-Logging in einer zentralen Compliance-Plattform aggregieren. Quality-Gates so konfigurieren, dass Pull-Request-Reviews tatsächlich vom Entwickler-Pool getrennt sind.
SAP Help Portal. "Git-Enabled Change and Transport System (gCTS)". help.sap.com/docs/ABAP_PLATFORM_NEW. Abgerufen Mai 2026. SAP Help Portal. "SAP Cloud Transport Management". help.sap.com/doc/64d7df2dac3d41ab83a257e9336d15af, März 2026. SAP Community. "gCTS in SAP S/4HANA 2025". community.sap.com, Karin Spiegel, Oktober 2025. SAP Community. "How Change Request Management (ChaRM) Leverages Git-enabled CTS (gCTS)". community.sap.com, Dezember 2025. GitHub. "SAP/jenkins-library". github.com/SAP/jenkins-library. Mit dem Deprecation-Hinweis: "No further updates, bug fixes, or pull requests will be accepted after December 31, 2026". Abgerufen Mai 2026. GitHub. "SAP/project-piper-action". github.com/SAP/project-piper-action. Archiviert am 7. April 2026. abapGit Documentation. "ABAP Language Version". docs.abapgit.org, Februar 2026. abapcloud.com. "abapGit Tutorial: Version Control for ABAP Cloud and Classic ABAP". abapcloud.com/en/abapgit-tutorial, Februar 2026. SAP Community. "Setting up BTP ABAP Environment transport management with Cloud Transport Management Service". community.sap.com, August 2025. DSAG. "Investitionsreport 2026". DSAG-Veröffentlichung, Januar 2026. Basis Technologies. "ActiveControl". basistechnologies.com. Rev-Trac. "Rev-Trac Documentation". rev-trac.com. REALTECH. "SmartChange". realtech.com. ReleaseOwl. "ReleaseOwl Documentation". releaseowl.gitbook.io.
"SAP-Hinweis 11599: Transport-Irreversibilität als Architektur-Argument", "MCP Server Governance für SAP", "EU AI Act und SAP-Landschaften, Welche Deployer-Pflichten ab August 2026 gelten", "Audit Trail Cross-Cutting EU AI Act, SOX, NIS2, DORA", "SAP Cloud ALM, Lücken im Change Management Stand 2026".
Christian Steiger ist Mitgründer und Geschäftsführer der Solutive AG und beschäftigt sich seit über 15 Jahren mit SAP-Application-Lifecycle-Management, Change Orchestration und Transport-Governance in komplexen Landschaften. Dieser Artikel ist als rein SAP-technischer Beitrag ohne Co-Autor verfasst. Die technischen Aussagen basieren auf öffentlich verfügbarer SAP-Dokumentation, dem GitHub-Repository-Stand vom Mai 2026 und der DSAG-Investitionserhebung 2026.
Das Change Orchestration Institute ist eine unabhängige Wissensressource für SAP ALM, Change Orchestration und KI-Governance. Initiator und Research-Partner: Solutive AG, solutive.ag/kontakt.