Continuous Integration 24.06.2024, 07:12 Uhr

Andauernd abliefern: CI/CD-Systeme überwachen

Continuous Integration und Continuous Delivery/Deployment bauen ein Produkt aus seinen Bausteinen schnell, hochqualitativ und in regelmässigen Abständen zusammen. Doch was ist, wenn das System versagt?
(Quelle: EMGenie)
Selbst wenn Entwickler Code mit hoher Geschwindigkeit schreiben, benötigen sie ein stabiles CI/CD-System (Continuous Integration und Continuous Delivery/Deployment), um diese Änderungen konsistent und effizient an die Endnutzer weiterzugeben. Je grösser die Teams werden, desto schwieriger wird es, ihre Updates zu verwalten und zu erhalten. Im Laufe der Zeit nimmt die Anzahl und Komplexität der Pipelines in der Regel ebenso zu wie die Grösse der Testsuiten. Zudem integrieren Entwickler Änderungen (Commits) häufiger und in kleineren Inkrements, um sicherzustellen, dass Probleme schnell entdeckt werden und geringere Auswirkungen haben. 
All diese Faktoren belasten das CI/CD-System zusätzlich und erhöhen das Risiko, dass Pipelines nicht funktionieren. Wird eine Pipeline unterbrochen, kann die Bereitstellung vollständig abbrechen, sodass die Teams die Fehlerbehebung manuell durchführen müssen. Ohne die richtigen Beobachtungstools kann ein solcher Ausfall Tage dauern, die Bereitstellung neuer Funktionen verzögern und damit die Effizienz und Geschwindigkeit der Anwendungsentwicklung verringern.
Um diese Hürden zu überwinden, setzen immer mehr Unternehmen spezielle Platform-Engineering-Teams ein, die für die Implementierung und den Betrieb von CI/CD-Systemen verantwortlich sind. Plattformingenieure sollen sicherstellen, dass die CI/CD-Infrastruktur ordnungsgemäss bereitgestellt wird, die Leistung der Pipeline verbessern und Tools konfigurieren, damit die Entwicklungsteams effizient arbeiten können.

Effektive Fehlerbehebung bei CI/CD-Problemen

Wenn im CI/CD-System etwas schiefläuft, sind Monitoring-Dashboards eine gute Möglichkeit, Probleme schnell zu erkennen und zu beheben. Sie sollten auf konkrete Problemfelder beschränkt sein, zum Beispiel Provider, Infrastruktur, Pipelines oder andere Abhängigkeiten. Damit ist die Fehlerquelle bereits eingegrenzt, bevor eine tiefere Suche beginnt. Einige Monitoring-Plattformen bieten auch die Möglichkeit, Dashboards miteinander zu verlinken. Das erleichtert die Orientierung.
Auf die Dashboards sollten ausserdem alle Ebenen der Entwicklung Zugriff haben. Denn Unternehmen aktualisieren Code immer häufiger und verlassen sich zum Testen und Bereitstellen ihrer Änderungen auf immer mehr Pipelines. Bei geteiltem Zugriff auf dieselben Dashboards können alle Beteiligten die letzten Fehler sehen. Ausserdem bieten sie einen detaillierten Kontext, um die Ursache des Problems zu lösen. Ein CI/CD-Überwachungstool wie Pipeline Visibility kann sofort einsatzbereite Dashboards bereitstellen. Sie stellen einen guten Ausgangspunkt für die Fehlerbehebung in CI/CD-Workflows dar, insbesondere wenn diese skaliert werden.

Monitoring: Viel und präzise

Um kritische Probleme zu erkennen, sollte eine breite Palette von Monitoren konfiguriert werden, die das gesamte CI/CD-System abdecken. Wird beispielsweise GitLab als CI-Provider verwendet, sollten Sie den Zustand Ihrer GitLab-Infrastruktur sowie alle Abhängigkeiten wie Redis (für das Caching), Sidekiq (für Warteschlangen zur Auftragsverarbeitung) und etcd (für die Speicherung von Aufträgen, die auf Kubernetes-Pods ausgeführt werden) überwachen.
Viele spezialisierte Monitore vermeiden, dass Probleme übersehen werden und können somit auch die Zeit bis zur Lösung verkürzen. Viele Probleme sind sehr speziell. Je präziser Monitore definiert werden, desto genauer lässt sich die Fehlerquelle eingrenzen. GitLab prüft beispielsweise regelmässig, ob verwaiste Pods vorhanden sind und löscht diese über eine Pod-Cleanup-Anwendung, die im Kubernetes-Cluster ausgeführt wird. 
Wenn die Anfrage nicht erfolgreich ist, kann dies zu verwaisten Pods führen, die weiterhin Ressourcen verbrauchen. Das verlangsamt andere GitLab-Aufträge und unter Umständen die gesamte Pipeline. Ein Monitor, der speziell dieses Problem verfolgt, bietet mehr Handlungsmöglichkeiten als einer, der lediglich über eine allgemeine Verlangsamung der Pipeline informiert.

Der Einfluss der Anwendung

Wenn sich Entwickler auf das Schreiben und Ausliefern von Code konzentrieren, kann es passieren, dass ihre Änderungen die Leistung der Pipeline negativ beeinflussen. Das führt zwar nicht unbedingt zu einem Ausfall, verlangsamt aber den gesamten Prozess, etwa das Zwischenspeichern von Daten, das Laden von Artefakten und das Ausführen von Funktionen. Diese kleinen Änderungen können leicht unbemerkt bleiben. Insbesondere, wenn nicht klar ist, ob eine langsame Bereitstellung auf Änderungen im Code oder auf andere externe Faktoren wie Netzwerklatenz zurückzuführen ist. Wenn diese Commits jedoch im Laufe der Zeit kompiliert werden, führen sie zu spürbaren Einbrüchen in der Entwicklungsgeschwindigkeit und lassen sich nur schwer rückwirkend erkennen und ändern. Wenn ein Entwickler langsame Tests oder andere Änderungen vornimmt, die die Pipeline beeinträchtigen, wirkt sich dies auf die Geschwindigkeit der Softwarebereitstellung der anderen Teammitglieder aus.

Konsequenz: Der Schlüssel zur Kontinuität

Durch die konsequente Überwachung können Entwicklungsteams eine Verschlechterung der Pipelines verhindern und optimierungsbedürftige Aufträge nach Priorität ordnen. Je umfassender und präziser das Monitoring ausfällt, desto schneller können IT-Teams Hindernisse identifizieren und sie beseitigen. Eine kontinuierliche Überwachung der CI/CD-Prozesse und ihre Anpassung helfen dabei, dass sich Probleme nicht anhäufen. Das erleichtert dann zum einen die Arbeit der Teams und individuellen Entwickler und macht den CI/CD-Zyklus für das gesamte Unternehmen und alle Anwender berechenbarer. Und das schafft wirtschaftliche Planbarkeit, Effizienz und Zuverlässigkeit.
Quelle: Stefan Marx
Stefan Marx
ist Director Platform Strategy beim Cloud-Monitoring-Anbieter Datadog. Marx ist seit über 20 Jahren in der IT-Entwicklung und -Beratung tätig. In den vergangenen Jahren arbeitete er mit verschiedenen Architekturen und Techniken wie Java Enterprise Systemen und spezialisierten Webanwendungen. Seine Tätigkeitsschwerpunkte liegen in der Planung, dem Aufbau und dem Betrieb der Anwendungen mit Blick auf die Anforderungen und Problemstellungen hinter den konkreten IT-Projekten.



Das könnte Sie auch interessieren