Messung und Überwachung der CI/CD-Performance
Die kontinuierliche Verbesserung zählt zu den Grundpfeilern der DevOps-Philosophie.
Sie umfasst alle Aspekte der Softwareentwicklung – von Ihrem Produkt oder Service bis hin zur Kultur und den Prozessen Ihres Unternehmens.
Kontinuierliche Verbesserung setzt voraus, dass Sie Rückmeldungen zu Ihren Arbeitsergebnissen oder -prozessen erfassen und analysieren, um zu verstehen, was gut funktioniert und was verbessert werden könnte. Nachdem Sie diese Erkenntnisse umgesetzt haben, sammeln Sie weiteres Feedback, um zu sehen, ob die vorgenommenen Änderungen die Messnadel in die richtige Richtung bewegt haben. Bei Bedarf nehmen Sie weitere Änderungen vor.
Eine CI/CD-Pipeline leistet einen zentralen Beitrag zur kontinuierlichen Verbesserung Ihrer Software. Indem Sie die Zeit von der Entwicklung bis zur Bereitstellung verkürzen, können Sie Änderungen häufiger für Ihre Benutzer*innen freigeben und erhalten so Feedback aus der produktiven Nutzung. Auf dieser Grundlage können Sie Ihre Prioritäten für die Zukunft anpassen. Außerdem erleichtert das schnelle Feedback aus jeder Phase Ihres automatisierten Testablaufs die Behebung von Fehlern und hilft Ihnen, die Qualität Ihrer Software zu gewährleisten.
Aber die kontinuierliche Verbesserung hört hier noch nicht auf. Indem Sie dieselben Methoden auch auf die CI/CD-Pipeline selbst anwenden, können Sie den Build-, Test- und Release-Prozess Ihrer Software optimieren, sodass die Feedback-Schleifen, die zur Verbesserung Ihres Produkts dienen, verstärkt werden.
Pipeline-Messdaten verstehen
Ein alter Spruch lautet: „Was du nicht misst, kannst du nicht steuern“.
Messdaten sind ein grundlegendes Werkzeug zur Verbesserung der Systemleistung: Sie helfen zu erkennen, wo Sie einen Mehrwert erzielen können, und sie bieten Referenzpunkte, um die Wirksamkeit Ihrer Verbesserungen zu beurteilen.
Die CI/CD-Performance umfasst sowohl die Geschwindigkeit als auch die Qualität. Sie sollten nicht zwischen der schnellen Umsetzung von Änderungen und der Bereitstellung eines robusten und zuverlässigen Produkts wählen müssen – eine leistungsstarke CI/CD-Pipeline ermöglicht beides.
Durch Messen und Überwachen der Geschwindigkeit Ihrer Abläufe, der Qualität Ihrer Software und des Automatisierungsumfangs können Sie Verbesserungspotenziale identifizieren und nach der Umsetzung von Änderungen überprüfen, ob sich diese positiv ausgewirkt haben.
Zentrale DevOps-Kennzahlen
Die folgenden vier Kennzahlen wurden von DevOps Research and Assessment (DORA) als übergeordnete Metriken identifiziert, die einen verlässlichen Hinweis darauf geben, wie gut ein Unternehmen im Kontext der Softwareentwicklung aufgestellt ist.
You can learn more about the research that informed these choices in the book Accelerate.
Vorlaufzeit
Die Vorlaufzeit (auch als Bereitstellungszeit oder Markteinführungszeit bezeichnet) im Sinne der Zeit von der ersten Thematisierung einer Funktion bis zur Freigabe für den Benutzereinsatz lässt sich zwar messen, aber die Zeit, die für Ideenfindung, Benutzerforschung und Prototyping benötigt wird, ist in der Regel sehr variabel.
Aus diesem Grund misst DORA die Zeit vom Commit des Codes bis zum Deployment. Dadurch können Sie sich nur auf die Phasen konzentrieren, die zu Ihrer CI/CD-Pipeline gehören.
Eine lange Vorlaufzeit bedeutet, dass Ihre Codeänderungen nicht regelmäßig Ihre Benutzer*innen erreichen und Sie daher nicht ihr Feedback nutzen können, um Ihr Produkt zu verbessern. Dies kann an mehreren Faktoren liegen.
Eine Release-Pipeline, die manuelle Schritte umfasst, zum Beispiel eine große Anzahl manueller Tests, Risikobewertungen oder Änderungsprüfungen, kann den Prozess um Tage oder Wochen verlängern und dadurch die Vorteile häufiger Releases untergraben.
Dem ersten Problem können Sie durch Investitionen in die Testautomatisierung entgegenwirken. Das zweite Problem erfordert die Einbindung der Beteiligten, um zu verstehen, wie ihre Bedürfnisse effizienter erfüllt werden können. Sollten automatisierte Schritte zu langsam oder unzuverlässig sein, können Messwerte zur Builddauer verwendet werden, um zeitraubende Phasen zu identifizieren.
Deployment-Häufigkeit
Die Deployment-Häufigkeit gibt an, wie oft Sie mithilfe Ihrer CI/CD-Pipeline Ihre Software für den Produktiveinsatz bereitstellen. Die Deployment-Häufigkeit wurde von DORA als Näherungsvariable für die Batchgröße ausgewählt, da eine hohe Deployment-Häufigkeit weniger Änderungen pro Deployment bedeutet.
Die Bereitstellung einer kleinen Anzahl von Änderungen verringert häufig das Risiko, das mit dem Release verbunden ist, da es weniger Variablen gibt, deren Kombination zu unerwarteten Ergebnissen führen kann. Außerdem erhalten Sie dadurch schnellere Rückmeldungen.
Eine niedrige Deployment-Häufigkeit kann bedeuten, dass die Pipeline nicht mit regelmäßigen Commits gefüttert wird (vielleicht weil Aufgaben nicht aufgeteilt werden), oder dass Änderungen in größeren Releases zusammengefasst werden.
Wenn Änderungen aus geschäftlichen Gründen (z. B. aufgrund von Benutzererwartungen) zusammengefasst werden müssen, können Sie stattdessen die Deployment-Häufigkeit auf Staging-Sites messen, um die Batchgröße im Blick zu behalten und zu beurteilen, ob Sie von den Vorteilen kleiner Arbeitsschritte profitieren.
Ausfallrate von Änderungen
Die Ausfallrate von Änderungen gibt den Anteil der Änderungen an, die nach der Produktivsetzung zu einem Ausfall führen, zum Beispiel einer Betriebsunterbrechung oder einem Bug, der entweder ein Rollback oder einen Hotfix erfordert. Der Vorteil dieser Kennzahl besteht darin, dass fehlgeschlagene Bereitstellungen in den Kontext des Änderungsumfangs gestellt werden.
Eine niedrige Änderungsausfallrate gibt Ihnen Vertrauen in Ihre Pipeline. Sie ist ein Hinweis darauf, dass die vorgeschalteten Pipeline-Phasen wie vorgesehen funktionieren und die meisten Fehler abfangen, bevor Ihr Code in die Produktion übernommen wird.
Mittlere Wiederherstellungszeit
Die mittlere Wiederherstellungszeit (mean time to recovery/resolution, MTTR) gibt die Zeit an, die benötigt wird, um einen Ausfall in der Produktion zu beheben. Mit dieser Maßzahl erkennen wir an, dass in einem komplexen System mit vielen Variablen gelegentliche Ausfälle in der Produktion unvermeidlich sind. Anstatt nach Perfektion zu streben (und dabei Releases zu verzögern und die Vorteile häufiger Releases zu verlieren), stellen wir die schnelle Reaktion auf Probleme in den Vordergrund.
Um Ihre MTTR niedrig zu halten, ist einerseits eine proaktive Überwachung Ihres Produktionssystems erforderlich, um auftretende Probleme sofort zu erkennen, und andererseits müssen Sie die Möglichkeit haben, Änderungen entweder rückgängig zu machen oder schnell einen Fix über die Pipeline bereitzustellen.
Eine verwandte Kennzahl ist die mittlere Erkennungszeit (mean time to detection, MTTD). Sie misst die Zeit zwischen der Bereitstellung einer Änderung und der Erkennung eines durch diese Änderung verursachten Problems durch Ihr Überwachungssystem. Indem Sie die MTTD zur Builddauer in Bezug setzen, können Sie ermitteln, ob Sie durch Investitionen in einen der beiden Bereiche Ihre MTTR reduzieren könnten.
CI- und Operations-Kennzahlen
Neben diesen allgemeinen Kennzahlen gibt es eine Reihe von operativen Messdaten, mit deren Hilfe Sie die Leistung Ihrer Pipeline besser verstehen und Bereiche identifizieren können, in denen Ihr Prozess möglicherweise verbesserungsfähig ist.
Code-Coverage
In einer CI/CD-Pipeline sollten automatisierte Tests den Großteil Ihres Testumfangs ausmachen, sodass sich Ihr QA-Personal auf explorative Tests und die Erstellung neuer Testfälle konzentrieren kann. Die erste automatisierte Testebene sollte Unit-Tests enthalten, da diese am schnellsten ausgeführt werden und unmittelbares Feedback bieten.
Die Code-Coverage ist eine Kennzahl, die von den meisten CI-Servern berechnet wird und den Anteil des Codes angibt, der von Ihren Unit-Tests abgedeckt wird. Es lohnt sich, diesen Wert zu beobachten, um sicherzustellen, dass Sie beim Schreiben von neuem Code eine angemessene Testabdeckung aufrechterhalten. Wenn Ihre Code-Coverage im Laufe der Zeit nach unten tendiert, ist es an der Zeit, etwas Arbeit in diese erste Feedback-Schleife zu investieren.
Builddauer
Die Builddauer gibt die Zeit an, die benötigt wird, um die verschiedenen Phasen der automatisierten Pipeline zu durchlaufen. Es ist nützlich, die in den einzelnen Phasen des Prozesses aufgewendete Zeit im Blick zu behalten, um Schwachstellen oder Engpässe zu erkennen, die sich auf die Gesamtdauer auswirken und so die Verfügbarkeit von Testfeedback oder die Live-Bereitstellung verzögern.
Erfolgsrate von Tests
Die Testerfolgsrate ist der Prozentsatz der Testfälle, die bei einem bestimmten Build erfolgreich bestanden wurden. Einen angemessenen Umfang an automatisierten Tests vorausgesetzt, ist diese Kennzahl ein guter Indikator für die Qualität der einzelnen Builds. Anhand dieses Werts können Sie nachvollziehen, wie oft Codeänderungen zu fehlgeschlagenen Tests führen.
Auch wenn das Erkennen von Fehlern mittels automatisierter Tests manuellen Tests oder Fehlern in der Produktion vorzuziehen ist, kann es sich lohnen, etwas Ursachenforschung zu betreiben, wenn ein bestimmter automatisierter Test regelmäßig fehlschlägt.
Behebungszeit von Testfehlern
Die Testfehler-Behebungszeit ist die Zeit zwischen dem Auftreten eines Testfehlers bei einem Buildvorgang und dem Bestehen desselben Tests durch einen nachfolgenden Build. Diese Kennzahl ist ein Hinweis darauf, wie schnell Sie auf Probleme reagieren können, die in der Pipeline identifiziert wurden.
Eine kurze Behebungszeit bestätigt, dass Sie Ihre Pipeline optimal nutzen. Indem Sie Probleme direkt nach ihrem Entdecken angehen, arbeiten Sie effizienter, da die Änderungen noch mental präsent sind. Außerdem vermeiden Sie, dass instabiler Code als Grundlage für weitere Funktionen verwendet wird.
Fehlgeschlagene Deployments
Fehlgeschlagene Bereitstellungen, die zu einem unerwarteten Ausfall führen, erfordern ein Rollback oder die dringende Veröffentlichung einer Korrektur. Wie oben angemerkt wird die Anzahl der fehlgeschlagenen Bereitstellungen zur Berechnung der Änderungsausfallrate verwendet.
Die Überwachung des Ausfallanteils an der Gesamtzahl der Bereitstellungen hilft dabei, Ihre Leistung zu SLAs in Bezug zu setzen.
Zu beachten ist allerdings, dass null (oder sehr wenige) fehlgeschlagene Deployments nicht unbedingt ein realistisches Ziel sind. Dies kann das Team dazu verleiten, die Sicherheit zu stark in den Mittelpunkt zu stellen. Das Ergebnis sind längere Vorlaufzeiten und größere Deployments, da Änderungen gebündelt werden, was wiederum die Wahrscheinlichkeit von Ausfällen in der Produktion erhöht (da es mehr Variablen gibt) und die Behebung erschwert (da mehr Änderungen überprüft werden müssen).
Defektanzahl
Im Gegensatz zu Ausfällen bezieht sich die Defektanzahl auf die Anzahl der offenen Tickets in Ihrem Backlog, die als Bugs klassifiziert wurden. Dieser Wert kann weiter aufgeschlüsselt werden, je nachdem, ob der Defekt in der Test- bzw. Staging-Phase oder in der Produktion entdeckt wurde.
Wie die Code-Coverage hilft auch die Defektanzahl, einen allgemeinen Trend zu erkennen, der ein Hinweis darauf sein kann, dass die Fehler außer Kontrolle geraten. Zu bedenken ist dabei jedoch, dass diese Kennzahl Teams dazu verleiten kann, sich mehr um die Klassifizierung von Tickets zu kümmern als um ihre Behebung.
Deployment-Größe
Als Pendant zur Deployment-Häufigkeit (siehe oben) kann die Deployment-Größe – angegeben durch die Anzahl der Story Points, die in einem Build oder Release enthalten sind – verwendet werden, um die Batchgröße innerhalb eines Teams im Auge zu behalten.
Kleine Deployments zeigen, dass Ihr Team regelmäßige Commits vornimmt – mit allen damit verbundenen Vorteilen. Da jedoch Story-Schätzungen unterschiedlicher Entwicklungsteams nicht miteinander vergleichbar sind, sollte dieser Wert nicht verwendet werden, um die Gesamtgröße von Deployments zu messen.
Fazit
Die Überwachung dieser Kennzahlen vermittelt Ihnen einen guten Überblick darüber, wie Ihre CI/CD-Pipeline abschneidet und ob Sie sich in einem Auf- oder Abwärtstrend befinden.
Sie können dadurch auch Bereiche in Ihrem Prozess identifizieren, die einer genaueren Aufmerksamkeit bedürfen. Nachdem Sie eine Änderung vorgenommen haben, sollten Sie die relevanten Kennzahlen weiterhin beobachten, um sicherzustellen, dass die Änderung die beabsichtigte Wirkung erzielt.
Diese Kennzahlen können zwar nützliche Leistungsindikatoren sein, es ist jedoch wichtig, die Werte im Kontext zu beurteilen und zu überlegen, welche Verhaltensanreize durch die Priorisierung einer bestimmten Kennzahl geschaffen werden. Denken Sie daran: Das Ziel sind nicht die Zahlen selbst, sondern eine schnelle und zuverlässige Pipeline, die Ihnen hilft, Ihrer Benutzergemeinde einen kontinuierlichen Mehrwert zu bieten.