Effiziente CI/CD-Pipelines basieren auf fünf Best PracticesMöglichst identische Produktions- und Testumgebung

Continuous Integration, Continuous Delivery und Continuous Deployment sind gängige Methoden, um die Bereitstellung von Software zu automatisieren. CI/CD-Pipelines bilden einen zentralen Bestandteil dieser komplexen Prozesse. Um eine höchstmögliche Effizienz des Release-Workflows zu erzielen, sollten Best Practices zum Einsatz kommen.

Ob Continuous Integration, Continuous Delivery oder Continuous Deployment: Neuer Code für eine Anwendung durchläuft auf seinem Weg in Produktion bei all diesen Methoden sogenannte CI/CD-Pipelines, also automatisierte und Tool-gestützte Prozessketten. Da im Zuge der vielen Prozesse einiges schiefgehen kann, sollten die fünf Best Practices Anwendung finden.

Die Performance der Pipeline beachten

Die Anforderung an CI/CD-Pipelines sind häufige Aktualisierungen der Software bei gleichzeitig möglichst umfangreichem Testing. Zwischen diesen Gegensätzen gilt es, ein gesundes Mittelmaß zu finden. Eine verbesserte Infrastruktur und die Optimierung der Tests können bis zu einem gewissen Grad helfen.

Geraten Entwicklerteams allerdings an einen Punkt, wo ein Trade-Off unvermeidlich ist, zum Beispiel durch eine Einschränkung der Tests oder die Akzeptanz verlängerter Laufzeiten, sollten sie alle Entscheidungen mit den Stakeholdern besprechen und gut dokumentieren.

Die CI/CD-Umgebung isolieren und absichern

Die CI/CD-Umgebung hat in der Regel Zugriff auf die Codebasis der Anwendungen sowie verschiedene andere Umgebungen – etwa für die Tests – bis hin zur Produktion. Das CI/CD-System stellt somit ein lohnendes Ziel für Angreifer dar.

Daher sollten sich alle darüber im Klaren sein, dass die CI/CD-Umgebung ein Einfallstor für Hacker sein kann und sie diese entsprechend schützen müssen – etwa mit einer strengen Zugriffskontrolle.

Ausschließlich über die CI/CD-Pipeline deployen

Gerade zu Beginn kann die Umstellung auf eine CI/CD-Pipeline zu Stresssituationen führen. Dann kommt es vor, dass Entwicklerteams auf alte Deployment-Methoden ausweichen und Bugfixes an der Pipeline vorbei einspielen, um somit vermeintlich wertvolle Zeit bis zum Live-Gang zu sparen. Das sollten Unternehmen allerdings tunlichst vermeiden, denn auch in solchen Situationen haben CI/CD-Pipelines einen großen Wert:

Sie ermöglichen es, Standardverfahren für Tests, Integration und Bereitstellung durchzusetzen und so die Entwicklungspraktiken zu verbessern sowie die Qualität des Codes zu steigern. Qualitativ minderwertigen Code erkennt die Pipeline frühzeitig und sortiert ihn aus, sodass er nicht in Produktion gelangt und dort Probleme verursacht. Das CI/CD-System nimmt eine sogenannte „Gatekeeper“-Funktion ein und schützt vor Schad-Code. Das funktioniert allerdings nur, wenn auch alle Änderungen am Code die Pipeline durchlaufen.

Produktions- und Testumgebung möglichst identisch halten

DevOps und CI/CD sind Methoden, denen die Idee zugrunde liegt, möglichst kleine Änderungen an der Software anzustoßen, durchzutesten und zu deployen. Die nötigen Tests sollten auf einer Umgebung stattfinden, die möglichst identisch mit der Produktionsumgebung ist, um die Integrität der Software unter realen Bedingungen zu prüfen.

Sind Testumgebung und Produktion zu verschieden, kann es dazu kommen, dass problematische Änderungen im Test nicht mehr erkannt werden und erst in Produktion auftreten – und das sollte auf alle Fälle vermieden werden. Je weniger Unterschiede zwischen Test- und Produktionsumgebung bestehen, umso unwahrscheinlicher ist das Auftreten dieses Problems. Ein zentraler Punkt hierbei ist, die bestehenden Unterschiede und möglichen Auswirkungen zu kennen.

Nach Trunk-based Development vorgehen

In der Prozesskette sind menschliche Interaktionen ein großer Zeitfresser. Beispiele dafür sind das Zusammenführen von Code-Änderungen (Mergen), manuelle Schritte bei der Test-ausführung oder der Installation sowie manuelle Konfigurationsänderungen. Zusätzlich können menschliche Fehler unnötige Reparaturaufwände zur Folge haben.

Eine mögliche Methode, um diesem Risiko zu begegnen, ist das „Trunk-based Development“. Es ermöglicht, dass zum Zeitpunkt der Release-Entscheidung alle Änderungen schon an richtiger Stelle, dem sogenannten „Trunk“, vorliegen. Die Entwicklerteams müssen sie somit nicht noch manuell in einen Release-Branch übertragen und prüfen. Voraussetzung dafür ist allerdings, dass der Trunk auch tatsächlich jederzeit Release-fähig ist. Änderungen, die dazu führen, dass er diese Eigenschaft verliert, sollten sofort zurückgerollt werden. Idealerweise erfolgt dies automatisch durch die CI/CD-Pipeline, die somit als Sicherheitsnetz fungiert.

Lutz Keller ist Leiter DevOps beim IT-Dienstleister Consol.

Consol