ATC-Pipeline mit abapGit und CI/CD

Code-Qualität in der ABAP-Welt ist heute Workflow, nicht Disziplin. Wir richten abapGit + ATC + Pipeline-Integration so ein, dass jeder Commit automatisch geprüft wird – Pflicht-Checks, Stil-Checks, domänenspezifische Checks. Findings landen im Backlog mit Owner und Tier-Klassifikation, Code-Reviews haben den ATC-Befund als gemeinsamen Anker. So bleibt Code-Hygiene stabil, ohne dass das Team einen separaten Review-Tisch braucht.

Vom Code-Review-Mail zum Workflow

ABAP-Entwicklung lief in vielen Schweizer Häusern lange als "schick mir mal kurz dein Programm rüber, ich schau drauf". Das hat zwei Probleme: Reviews sind asynchron-stehend, und der Reviewer prüft nach Gefühl statt nach Regel. Beides bricht, sobald das Team wächst oder die Code-Basis komplex wird.

Eine professionelle ABAP-Pipeline löst das. abapGit + ATC + CI/CD-Integration macht aus Code-Hygiene einen Workflow, der automatisch läuft und konsistent prüft.

Die drei Bausteine

abapGit – Version-Control in ABAP

Mit abapGit verwalten wir Eigenentwicklungen in einem Git-Repository (typisch GitHub, GitLab, Azure DevOps). Jede Änderung läuft als Branch + Pull-Request. Damit kommen die Standard-Patterns der modernen Softwareentwicklung in die ABAP-Welt: Branches für Features, Pull-Requests für Reviews, History für jede Zeile, Diff zwischen Versionen.

Der Vorteil ist nicht nur Versionierung – abapGit erlaubt auch Code-Migration zwischen Systemen ohne Transport-Schmerz: Sandbox-Entwicklung, dann Pull in Dev, dann in Q. Transports laufen automatisiert.

ATC – die Pflicht-, Stil- und Domänen-Checks

Der ATC wird mit drei Check-Stufen konfiguriert (siehe auch Custom-Code-Cleanup):

• Pflicht-Checks – SAP-Standard-Checks für S/4-Readiness, Sicherheit, Performance, Open SQL-Konformität, Released-API- Disziplin
• Stil-Checks – Clean-ABAP-Konventionen, Modul-Größen, Variablen-Namen, Inline-Deklarationen, nach Ihrer Code-Norm
• Domänen-Checks – kundenspezifische Regeln (z.B. Verbot direkter SELECT auf Buchhaltungstabellen, Modul-Konventionen)

Jede Check-Stufe hat eine eigene Tier-Klassifikation: Pflicht- Findings sind Tier-1 (blockieren Merge), Stil-Findings sind Tier-3 (kosmetisch), domänenspezifische Findings landen je nach Schwere in Tier-1 oder Tier-2.

CI/CD-Integration – Pipeline-Trigger

Die Pipeline (typisch GitHub Actions, GitLab CI, Azure DevOps) triggert auf jeden Pull-Request:

1. Code wird in eine Test-Sandbox ausgespielt
2. ATC läuft mit allen drei Check-Stufen
3. Findings werden als Pull-Request-Kommentar zurückgespielt
4. Tier-1-Findings blockieren den Merge automatisch
5. Bei sauberem Lauf wird der Pull-Request freigegeben für Review

Damit prüft die Pipeline die technischen Regeln, der menschliche Reviewer prüft die fachliche Richtigkeit – Aufgaben-Trennung die Code-Reviews deutlich produktiver macht.

Was sich für das Team ändert

Vorher

• Code-Review nach Tagen, mit "schau mal kurz drauf"
• Stil-Diskussionen in jedem Review neu (Tab vs. Space, Namens-Konventionen)
• Sicherheits- und Performance-Findings werden vergessen
• Code-Qualität schwankt zwischen Entwicklern

Nachher

• Pull-Request-Review innerhalb von Stunden
• Stil ist nicht-verhandelbar (ATC entscheidet), Diskussion ist um Fachlichkeit
• Sicherheits-Findings können nicht gemerged werden
• Code-Qualität ist messbar (Tier-Verteilung pro Modul)

Praktische Schritte zum Start

1. abapGit-Repository aufsetzen (1 Tag): einer Ihrer Z-Pakete als Pilot, abapGit-Plugin im S/4 installieren, Repo verbinden
2. ATC-Profil definieren (2 Tage): Pflicht-Checks aktivieren, Stil-Konventionen festlegen, erste Domänen-Regeln formulieren
3. Pipeline schreiben (3-5 Tage): GitHub Actions oder GitLab CI Konfiguration, ATC-Trigger, Pull-Request-Kommentar-Integration
4. Team-Onboarding (1 Sprint): Pull-Request-Workflow einüben, Tier-Klassifikation gemeinsam besprechen
5. Bestandscode-Cleanup läuft parallel als Backlog (Wochen bis Monate)

Wir bringen die Patterns mit – kein Erfinden des Rads bei jedem Kunden.

SFOUR Consulting — Übersicht · Kontakt