Das Buchungsportal der Nordlicht Reisen GmbH wird häufig geändert, und jede Änderung soll nur dann weiterlaufen, wenn bestimmte Bedingungen erfüllt sind: die Tests grün, die Abdeckung der geänderten Zeilen ausreichend, die Antwortzeit unter einer Grenze, nach der Auslieferung keine Alarme. Niemand soll dafür von Hand Häkchen setzen. Sie sollen die Tore (gates) entwerfen, die Teststrategie dahinter festlegen und entscheiden, wo Tests, Abdeckung und Lasttests in der Kette stehen. Das sind die Fähigkeiten dieser Lektion: Qualitäts- und Freigabetore (auch für Sicherheit und Regelwerk), Teststrategie (lokal, Einheit, Integration, Last), Tests und Testagents in einer Pipeline und Codeabdeckung.

Vorwissen: Wie Sie Testergebnisse und Zeilenabdeckung in einer Pipeline sichtbar machen und warum der Exit-Code zählt, steht in K3, Lektion 3.7.3; Lasttests mit Azure Load Testing, Fehlerkriterien und die Kosten in Virtual User Hours in K3, Lektion 3.8.6; Genehmigungen, Umgebungen und das Zurückrollen in K3, Lektion 3.7.6. Branch Policies und Schutzregeln kennen Sie aus Lektion 2.2, die Parallelität von Jobs aus Lektion 4.3. Diese Lektion wiederholt das nicht, sondern ordnet es zu einer Strategie.

Nicht gegen Azure, GitHub oder Azure DevOps ausgeführt; aus der Referenz von Microsoft und GitHub: Alle Befehle, YAML-Dateien und Menüpfade dieser Lektion stammen aus der Dokumentation oder sind aus ihr abgeleitet; sie sind in diesem Kurs nicht ausgeführt worden.

Qualitäts- und Freigabetore

Was ein Tor ist

Ein Tor ist eine Regel, die ohne eine Person darüber entscheidet, ob eine Änderung zum nächsten Schritt weiterlaufen darf. Eine Genehmigung ist dagegen eine Entscheidung einer Person (Lektion 4.7). Beides gehört zusammen, aber die Tore sind der Teil, der bei jeder Änderung ohne Zutun gleich ausfällt. Microsoft nennt als Einsatzfälle für Tore unter anderem:

  • Qualitätsprüfung: Kennzahlen der Pipeline wie Erfolgsquote der Tests oder Codeabdeckung abfragen und nur ausliefern, wenn sie in der vorgegebenen Spanne liegen.
  • Sicherheitsprüfung: Artefakte untersuchen, Code signieren, Richtlinien prüfen; ein Tor kann den Scan starten und auf sein Ende warten oder nur prüfen, ob er fertig ist.
  • Vorfallsverwaltung: nur ausliefern, wenn keine Fehler der höchsten Dringlichkeit offen sind.
  • Änderungsverwaltung: auf ein Verfahren in einem System wie ServiceNow warten.
  • Zustand der Infrastruktur: nach der Auslieferung prüfen, ob die Ressourcen gesund sind und die Regeln einhalten.

Wichtig ist der Gedanke dahinter: Die meisten Gesundheitswerte schwanken zwischen gesund und ungesund. Deshalb werden Tore wiederholt ausgewertet, bis alle im selben Durchgang bestehen, oder die Zeit läuft ab und die Auslieferung wird abgelehnt.

Wo Tore in der Kette sitzen

Eine Kette hat mehrere Stellen, an denen ein Tor sinnvoll ist. Die Reihenfolge ist zugleich eine Reihenfolge von billig nach teuer:

Stelle Beispiel für ein Tor Azure DevOps GitHub
vor dem Zusammenführen Tests grün, Abdeckung der geänderten Zeilen, Analysen Branch Policy mit Build-Validierung, Statusprüfung Pflicht-Statusprüfungen in einem Regelwerk (Lektion 2.2)
im Build Tests laufen, Mindestzahl an Tests, Abdeckung wird veröffentlicht Schritt scheitert, failOnMinTestsNotRun Schritt scheitert, Exit-Code
vor der Stufe Zweig geschützt, Vorlage vorgeschrieben, Artefakt erfüllt Richtlinie, Prüfdienst sagt ja Prüfungen (Checks) an der Umgebung oder Dienstverbindung Schutzregeln der Umgebung, benutzerdefinierte Schutzregeln
nach der Auslieferung keine Alarme, Lasttest bestanden, Gesundheitssignale Prüfung „Query Azure Monitor alerts“, Aufruf einer Funktion oder eines REST-Dienstes Folgejob mit Prüfung, bei Misserfolg Rückschritt

Wichtig für die Prüfung: Die Gates der klassischen Release-Pipelines und die Prüfungen (Checks) der YAML-Pipelines sind zwei Fassungen desselben Gedankens. Microsoft beschreibt Gates als Teil von Release-Pipelines (Vor- und Nachbedingungen einer Stufe, mit Verzögerung vor der Auswertung, Abstand zwischen den Auswertungen und Zeitgrenze; die kleinsten einstellbaren Werte sind sechs Minuten Zeitgrenze und fünf Minuten Abstand) und Prüfungen als Teil von Ressourcen wie Umgebungen. Die Signale sind dieselben: Alarme in Azure Monitor, Abfragen von Arbeitselementen, Aufrufe einer Azure Function oder eines REST-Dienstes. Die Aufgabe AzureMonitor@1 sagt ausdrücklich, dass sie in einem Release-Pipeline-Job ohne Agent läuft und erfolgreich ist, wenn zum Zeitpunkt der Abfrage keine Alarmregel ausgelöst ist.

Sicherheit und Regelwerk als Tore

„Governance“ meint hier: Wer eine Pipeline schreibt, soll die Regeln der Organisation nicht umgehen können. Azure Pipelines hat dafür Prüfungen, die nicht in der YAML-Datei stehen und deshalb von deren Autoren nicht verändert werden können (Lektion 4.7 zeigt alle):

  • Branch control: Die Quellen des Laufs müssen aus erlaubten Zweigen stammen, auf Wunsch mit eingeschaltetem Schutz.
  • Required template: Eine Pipeline scheitert, wenn sie nicht von der vorgeschriebenen Vorlage erbt. Das ist der Hebel, um Sicherheitsschritte in jede Pipeline zu zwingen (Lektion 4.4).
  • Evaluate artifact: Das Artefakt wird gegen eigene Richtlinien geprüft; Microsoft nennt als Einschränkung, dass das derzeit nur für Container-Images gilt.
  • Invoke REST API / Azure Function: Hier hängen Sie Dienste ein, die Microsoft nicht mitliefert. Auf die Frage, wie man auf den Abschluss eines Sicherheitsscans wartet, antwortet Microsoft: mit einem externen Scandienst und einer REST-Prüfung, die dessen Schnittstelle abfragt. Die Prüfung selbst scannt nichts.

Bei GitHub sitzt das Regelwerk in den Einstellungen des Repositorys und der Organisation: Regelwerke für Zweige (Lektion 2.2), Schutzregeln der Umgebung (Lektion 4.7) und, als öffentliche Vorschau laut GitHub, benutzerdefinierte Schutzregeln als GitHub App, die auf den Webhook deployment_protection_rule antwortet.

Zwei Entwurfsregeln aus Microsofts Leitfaden zu sicheren Bereitstellungen: Qualitätssignale müssen täglich beachtet werden, sonst schreibt ein Team Tests nur, um ein gelbes Zeichen grün zu machen. Und vor der Bereitstellung gehören Prüfungen wie Codereview, Sicherheitsscans und Konformitätsprüfungen zu den „Predeployment checks“; man verlässt sich dabei nicht auf eine Art Test, weil verschiedene Tests verschiedene Fehlerklassen finden.