DDC hakt nach: Wie bekomme ich CI/CD unter Kontrolle?
Es fängt immer gleich an: Die Pipeline ist sauber, aufgeräumt, alles schön modular – und dann? Sechs Monate später starrst du auf ein 500-Zeilen-YAML-Ungetüm, bei dem schon beim Scrollen das Terminal weint. Willkommen in der YAML-Pipeline-Hölle. Aber hey: Das muss nicht so sein. Marc Müller schenkt dir Abhilfe. Dazu musst Du nur seinen Workshop auf der .NET Developer Conference besuchen. Die zentralen Punkte hat er aber schon mal im Interview mit Developer World verraten.
Wider das 500- Zeilen- Monster: Was ist dein Geheimrezept für YAML-Pipelines, die auch nach zwei Jahren noch wartbar sind?
Marc Müller: In der Tat ist das Risiko bei YAML-Pipelines hoch, dass sie über die Zeit unwartbar werden. Dies liegt jedoch nicht an der YAML-Syntax oder der Pipelines-Infrastruktur, sondern meist daran, dass keine klaren Verantwortlichkeiten vorhanden sind und Pipelines nur nebenbei ein wenig gepflegt werden.
Generell gelten für Pipelines dieselben Regeln wie für die Softwareentwicklung: Kein Spaghetti-Code und keine Duplizierungen! Entsprechend sind Module, also Templates mit klar definierten Schnittstellen über Parameter, der richtige Weg. Die eigentliche Pipeline orchestriert dann nur noch den Aufruf dieser Module. Werden die Module von vielen Projekten oder Repositories genutzt, sollten sie in ein dediziertes Repository ausgelagert werden. Auf diese Weise können die Templates über Git-Referenzen versioniert eingebunden werden.
Das Wichtigste ist jedoch, die Pipeline nicht unnötig komplex werden zu lassen. Der gesamte Software-Bauprozess kann heute problemlos in ein Multi-Stage-Dockerfile ausgelagert werden, während die Pipeline nur noch den Build-Aufruf sowie den Export der Testergebnisse aus dem Container enthält.
Zudem sollten vermehrt Skript-Tasks verwendet werden. Diese Skripte sind portabel und können unabhängig von der Pipeline getestet oder ausgeführt werden. So bleibt die Pipeline überschaubar und gut wartbar.
Automatisierte Sicherheitsprüfungen in CI/CD – das predigen alle, aber in der Realität wird Security oft erst nachträglich draufgepappt. Wie integrierst du Sicherheitschecks so, dass sie den Flow nicht kaputt machen, aber trotzdem echten Schutz bieten?
Marc: Sicherheit ist heute ein entscheidender Faktor im gesamten Entwicklungs- und Betriebsprozess. Pipelines spielen dabei eine wichtige Rolle, sind aber nicht allein für die Sicherheit verantwortlich. Die sogenannten low-hanging fruits sollten möglichst früh im Projekt aktiviert werden. Microsoft bietet mit GitHub Advanced Security für GitHub und Azure DevOps genau diesen Ansatz: Mit wenigen Schritten erhält man Secret Scanning – damit keine Secrets im Quellcode landen – sowie Dependency Scanning, das vor unsicheren Abhängigkeiten warnt. Eine statische Codeanalyse deckt Implementierungsfehler auf.
Diese Mechanismen erweitern bestehende Pipelines und verursachen in der Regel nur Lizenzkosten und eine geringfügig längere Build-Zeit. Die Früherkennung von Sicherheitslücken zahlt sich jedoch mehrfach aus. Wichtig ist, dass dies nur die Basics sind. Auch die gesamte Build- und Deployment-Infrastruktur muss abgesichert werden, damit Angreifer diese nicht übernehmen und eine vermeintlich sichere Pipeline plötzlich Schadsoftware verteilt oder Secrets preisgibt.
Statische Sicherheitsmechanismen sind leicht umzusetzen, doch man sollte auch dynamische Analysen durchführen und die Software mit manuellen oder automatisierten Penetrationstests zur Laufzeit prüfen. Ebenso sollten Zielsysteme regelmäßig auf Konfigurationsfehler kontrolliert und mit Monitoring-Lösungen überwacht werden, um Anomalien oder verdächtige Aktivitäten zu erkennen.
Damit Sicherheitsprüfungen nicht zur Last werden, sollten sie so weit wie möglich automatisiert werden. Idealerweise wird der Entwickler direkt im aktiven Pull Request informiert. Je früher ein Problem erkannt und behoben wird, desto geringer sind die Gesamtkosten im Vergleich zu einer späteren Entdeckung im Betrieb.
Gibt es eine einfache Faustregel: Wann sollte ich Blue-Green nehmen, wann Canary und wann reicht vielleicht sogar ein klassisches Rolling-Update?
Marc: Darauf gibt es nur die klassische Beraterantwort: Es kommt darauf an. Zunächst ist es wichtig, ein automatisiertes Deployment zu haben, dass durch einen Trigger ausgelöst und automatisch überprüft wird. Diese Überprüfung kann von einem einfachen Smoke-Test – läuft es und steigt kein Rauch auf? – bis hin zu einer vollständigen Testsuite reichen. Teil dieser Validierung ist auch das Monitoring der ausgerollten Anwendung. Wie stabil läuft sie, wie viele Fehlermeldungen treten auf, wie entwickeln sich Nutzerzahlen und Performance?
Zur eigentlichen Frage: Die Wahl der Deployment-Strategie hängt davon ab, welches Ziel verfolgt wird und welche Ressourcen zur Verfügung stehen. Alle genannten Strategien haben eine gemeinsame Anforderung: Die Anwendung muss eine Zeit lang mit zwei Versionen parallel laufen können. Das bedeutet zum Beispiel, dass bei relationalen Datenbanken ein aktualisiertes Schema kompatibel mit beiden Versionen sein muss. Ist diese Herausforderung gelöst, kann die passende Strategie gewählt werden:
- Blue-Green-Deployment: Wenn die Anwendung auf einen Schlag und ohne Unterbrechung ausgeliefert werden soll. Die neue Version wird parallel bereitgestellt und bei Erfolg wird der Router oder DNS umgeschaltet. Lässt man das alte Deployment kurz bestehen, kann im Fehlerfall sofort zurückgerollt werden. Nachteil: kurzzeitig doppelte Ressourcen.
- Rolling Update: Wenn Ressourcen geschont werden sollen. Hier wird Instanz für Instanz aktualisiert, der Ressourcen-Overhead ist minimal.
- Canary-Deployment: Wenn Risiken minimiert werden sollen. Eine kleine Nutzergruppe (zum Beispiel fünf Prozent) erhält die neue Version zuerst. Fallen die Monitoring-Ergebnisse positiv aus (Fehler, KPIs, Zufriedenheit), wird die Verteilung schrittweise erhöht, bis 100 Prozent erreicht sind. Voraussetzung: Gute Überwachung sowohl technischer als auch geschäftlicher Auswirkungen.
Ein Canary-Ansatz kann auch über Feature Flags umgesetzt werden: Die neue Version wird ausgerollt, aber einzelne Funktionen bleiben deaktiviert. Sie können gezielt pro Nutzer oder Nutzergruppe freigeschaltet werden.
Die .NET Developer Conference 2025 findet vom 24. bis 27. November 2025 in Köln statt. Hier erfährst Du alles rund um Microsoft .NET, Architektur und AI. Marcs Workshop „CI/CD-Pipelines mit Azure DevOps meistern“ findet am Montag, dem 24. November 2025, ab 9.00 Uhr statt.
