CICDX

CICDX übersetzt CI/CD-Pipelines zwischen Jenkins, GitHub Actions, GitLab CI, CircleCI und Azure Pipelines — automatisch. Was von Hand eine Woche dauert, ist in Stunden erledigt.

Die Idee entstand daraus, diese Migrationen oft genug manuell gemacht zu haben, um zu merken: Das ist ein Übersetzungsproblem, kein Entwicklungsproblem. Jede Plattform drückt dieselbe Handvoll Konzepte aus — Stages, Matrix-Builds, Caching, Secrets, bedingte Ausführung — nur in einem eigenen Dialekt. Neunzig Prozent einer Migration sind mechanisches Umschreiben. Die restlichen zehn Prozent sind die Stelle, an der das eigentliche Nachdenken passiert.

Genau diese zehn Prozent richtig zu behandeln ist der schwierige Teil. Jenkins-Pipelines enthalten Groovy-Logik, für die es anderswo keine saubere Entsprechung gibt, und die Secrets-Verwaltung unterscheidet sich genug, dass eine naive Konvertierung etwas erzeugt, das korrekt aussieht und in Produktion still versagt. CICDX markiert solche Stellen, statt zu raten — ein Konverter, der lautlos falsch liegt, ist schlimmer als gar keiner.

Der typische Anlass für eine solche Migration ist selten technisch. Meistens ändert sich die Lizenzlage, ein Konzern gibt eine Plattform vor, oder der Betrieb der eigenen Jenkins-Installation ist über die Jahre teurer geworden als das SaaS-Angebot der Alternative. Die Entscheidung ist dann längst gefallen, und was bleibt, ist eine Menge Arbeit, die niemand gerne macht und die kein Team beschleunigt, indem es mehr Leute daraufsetzt.

Was uns beim Bauen am meisten überrascht hat, war die Rolle der Testabdeckung. Eine übersetzte Pipeline lässt sich nur dann guten Gewissens ausrollen, wenn man vorher weiß, welche Schritte überhaupt beobachtbar sind. Bei Teams mit einer belastbaren Testsuite ist eine Migration ein Nachmittag. Bei Teams ohne eine solche ist sie ein Vertrauensakt — und diese Diagnose liefert CICDX gleich mit, weil sie den Aufwand besser vorhersagt als die Größe der Pipeline.

Für unsere Beratungsarbeit ist CICDX gleichzeitig das eigene Testfeld für die Muster, die wir Kunden empfehlen: GitOps als einziger Weg in die Produktion, Karpenter-gesteuertes Autoscaling für die Build-Farm, Spot-Instanzen dort wo Unterbrechungen verkraftbar sind, und Kostenzuordnung pro Pipeline-Lauf. Was wir dort nicht selbst betreiben würden, empfehlen wir auch nicht weiter.

Was uns der Betrieb gelehrt hat, betrifft weniger die Übersetzung als die Erwartungen daran. Teams, die ein Werkzeug wie dieses einsetzen, wollen meist nicht nur eine funktionierende Pipeline, sondern eine, die aussieht wie von Hand geschrieben — mit denselben Namenskonventionen, denselben Kommentaren, derselben Reihenfolge. Ein Ergebnis, das korrekt ist und fremd wirkt, wird nicht übernommen, sondern nachbearbeitet, und dann war die Automatisierung umsonst. Lesbarkeit des Ergebnisses ist bei Übersetzungswerkzeugen deshalb keine Kür, sondern die Bedingung dafür, dass sie überhaupt benutzt werden.

Wenn Sie vor einer Plattform-Migration stehen, ist der nützlichste erste Schritt übrigens keiner, für den Sie uns brauchen: Zählen Sie, wie viele Ihrer Pipelines in den letzten sechs Monaten überhaupt geändert wurden. Erfahrungsgemäß ist es ein Bruchteil. Der Rest kann mechanisch übersetzt und danach vergessen werden — und damit schrumpft ein Projekt, das nach Monaten klang, oft auf zwei Wochen.

CICDX ist nicht nebenbei entstanden, sondern mit denselben Verfahren, die wir in Kundenprojekten anwenden. Diese drei Bereiche tragen das Produkt — und in einem Projekt bei Ihnen wären es dieselben: