Die Nordlicht Reisen GmbH hat über die Jahre viele Pipelines angesammelt. Einige laufen jede Nacht, obwohl sich nichts geändert hat, eine alte Release-Pipeline mit Genehmigungen wird von niemandem mehr verstanden, und der Speicher mit alten Läufen wächst. Sie sollen die Pflege der Pipelines planen: messen, wo es hakt, Kosten und Laufzeit senken, festlegen, was wie lange aufbewahrt wird, und die klassischen Pipelines nach YAML überführen. Das sind die Fähigkeiten dieser Lektion: Pipeline-Gesundheit überwachen, Kosten, Zeit, Leistung, Zuverlässigkeit und Gleichzeitigkeit optimieren, Aufbewahrung festlegen und klassische Pipelines nach YAML migrieren.

Vorwissen: Die vier Zahlen der Gesundheit (Fehlerrate, Zeit bis zum Urteil, zweite Versuche, Wartezeit), das Skript pipeline-health.ps1, Cache und parallele Jobs bei GitHub und die Aufbewahrung bei GitHub und Azure Pipelines in Grundzügen stehen in K3, Lektion 3.7.7. Runner, Agents und parallele Jobs vergleicht Lektion 4.2, Umgebungen mit Prüfungen Lektion 4.7, Alarme für Pipelines Lektion 6.1. Diese Lektion beginnt dort, wo K3 aufhört: bei vielen Pipelines, einer Organisation und der Altlast.

Nicht gegen Azure DevOps ausgeführt; aus der Referenz von Microsoft: Alle Befehle, YAML-Dateien und Menüpfade dieser Lektion stammen aus Microsofts Dokumentation und sind in diesem Kurs nicht ausgeführt worden. Die Seite von GitHub zu Aufbewahrung und Metriken wurde für diese Lektion nicht erneut gelesen; für GitHub gilt K3, Lektion 3.7.7.

Gesundheit überwachen

Die Berichte in Azure Pipelines

Jede Pipeline hat einen Reiter Analytics. Er fasst Erfolgsquote und Dauer zusammen; ein Klick auf die Karte öffnet den vollständigen Bericht. Die Quelle der Berichte sind die Läufe der Pipeline, gesammelt über einen Zeitraum. Drei Berichte stehen zur Wahl:

Bericht Was er zeigt Wozu Sie ihn nutzen
Pipeline pass rate Erfolgsquote und ihren Verlauf; Zusammenfassung (Standardzeitraum 14 Tage), Failure trend (Fehler je Tag, bei mehreren Stufen nach Stufe getrennt), Top failing tasks & their failed runs die Aufgabe finden, die die meisten Läufe zum Scheitern bringt, und zuerst die beheben
Pipeline duration wie lange die Pipeline üblicherweise bis zum Erfolg braucht; Verlauf; die Aufgaben mit der längsten Dauer die Aufgabe mit dem größten Anteil an der Laufzeit finden
Test failures die am häufigsten fehlschlagenden Tests mit Details Tests finden, die Läufe rot machen

Filtern können Sie nach Datumsbereich (Standard: die letzten 14 Tage) und nach Zweig. Der Zweigfilter ist wichtig: Eine Pipeline, die für Pull-Request-Zweige oft rot ist, aber auf main stabil, hat ein anderes Problem als eine, die auf main rot ist.

Von der Zahl zur Maßnahme

Eine Zahl ist erst nützlich, wenn eine Entscheidung daran hängt. Eine Tabelle, die Gesundheit und Pflege verbindet (die Zuordnung ist unsere, die Berichte sind die von Microsoft):

Befund Ursache liegt wahrscheinlich bei Maßnahme
eine Aufgabe führt die Liste der Fehler an der Aufgabe selbst oder ihrer Umgebung (Agent, Werkzeug, Netz) die Aufgabe beheben; wenn sie nur auf einem Agent scheitert, den Agent prüfen (Lektion 4.5)
die Dauer steigt langsam seit Wochen wachsender Umfang (Tests, Abhängigkeiten, Verlauf) Cache, flacher Abruf, Aufteilen (Lektion 4.3)
die Dauer springt plötzlich eine Änderung an Pipeline, Image oder Agent den Lauf vor und nach dem Sprung vergleichen
dieselben Tests scheitern wechselnd flackernde Tests reparieren statt neu starten (K3, Lektion 3.8.4)
die Erfolgsquote ist auf Zweigen niedrig, auf main hoch Pull Requests ohne lokale Prüfung Schutzregeln und lokale Prüfung (Lektion 2.2)

Alarme, wenn eine Pipeline rot wird, behandelt Lektion 6.1; hier geht es um das regelmäßige Hinsehen: einmal je Woche den Bericht der wichtigsten Pipelines.