Das Buchungsportal der Nordlicht Reisen GmbH wird in drei Umgebungen ausgeliefert: Test, Abnahme, Produktion. In die Produktion darf nur, was aus dem Hauptzweig kommt, was eine zuständige Person freigegeben hat und was nicht gleichzeitig mit einer zweiten Auslieferung läuft. Die Pipeline-Autoren sollen diese Regeln nicht aus Versehen oder mit Absicht aus der YAML-Datei streichen können. Das ist die Fähigkeit dieser Lektion: Prüfungen (checks) und Genehmigungen (approvals) mit YAML-basierten Umgebungen einrichten, in beiden Welten.
Vorwissen: Dass eine Auslieferung in eine Umgebung zwischen Stufen auf eine Genehmigung wartet, und wie Revisionen zurückrollen, lehrt K3, Lektion 3.7.6. Stufen und Bedingungen in Lektion 4.3, Tore als Entwurf in Lektion 4.6. Neu ist hier die Vollständigkeit: alle Prüfungen von Azure Pipelines im Einzelnen, ihre Reihenfolge, die Regeln für eigene Prüfungen, die Rollen und die Gegenstücke bei GitHub.
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.
Umgebungen in Azure Pipelines
Eine Umgebung (environment) ist eine Gruppe von Ressourcen, auf die eine Pipeline ausliefern kann, und steht für ein logisches Ziel wie Entwicklung, Test, Abnahme oder Produktion. Als Ressourcen unterstützt sie laut Microsoft derzeit Kubernetes und virtuelle Maschinen; eine leere Umgebung ist ebenfalls sinnvoll, als Anker für den Verlauf und für Prüfungen. Microsoft nennt vier Vorteile:
- Verlauf der Bereitstellungen: Pipeline und Lauf werden je Umgebung und Ressource festgehalten; mehrere Pipelines, die dasselbe Ziel ändern, sind in einem Verlauf sichtbar.
- Rückverfolgbarkeit von Commits und Arbeitselementen: Sie sehen, welche Commits und welche Arbeitselemente neu in der Umgebung sind (Lektion 1.1).
- Zustand der Ressourcen: ob die Anwendung im gewünschten Zustand läuft.
- Sicherheit: Sie legen fest, wer die Umgebung benutzen darf und welche Pipelines sie nutzen dürfen.
Umgebungen gibt es nur in YAML-Pipelines; für klassische Pipelines nennt Microsoft als ähnliche Einrichtung die Bereitstellungsgruppen (deployment groups).
Ansprechen im Deployment-Job
Ein Deployment-Job (Lektion 4.3) nennt die Umgebung mit environment:
- stage: Produktion
jobs:
- deployment: Web
environment: buchungsportal-prod
strategy:
runOnce:
deploy:
steps:
- script: echo Auslieferung
Die lange Form wählt eine Ressource der Umgebung, damit Verlauf und Verbindungsdaten auf die Ressource gehen:
environment:
name: buchungsportal-prod
resourceName: myVM
resourceType: virtualMachine
Mit environment: 'buchungsportal-prod.bookings' (Umgebung, Punkt, Ressource) erben die Schritte die Verbindung der Ressource, zum Beispiel eines Kubernetes-Namensraums. Bei Maschinen als Ressource brauchen Sie keinen Pool: Die Schritte laufen auf der Maschine.
Anlegen: Entweder im Portal von Azure DevOps (Pipelines, Environments, Create environment), oder automatisch, wenn die YAML-Datei eine Umgebung nennt, die es nicht gibt. Das gelingt nur, wenn Azure Pipelines den Anlegenden kennt, also bei der Erstellung der Pipeline im Assistenten oder beim Speichern im Web-Editor. Wer die Datei in einem externen Editor ändert und einen Lauf auslöst, bekommt einen Fehler, weil unbekannt ist, wer Administrator der neuen Umgebung werden soll. Früher wurden stattdessen alle Mitwirkenden zu Administratoren; Microsoft hat das abgestellt, damit niemand die Rechte der anderen ändert. Für die Namen gilt: Laufzeitparameter funktionieren in Umgebungsnamen nicht, weil sie erst zur Laufzeit erweitert werden; nehmen Sie Variablen oder templateContext.
Rollen und Pipeline-Berechtigungen
Die Benutzerrechte kennen vier Rollen:
| Rolle | Darf |
|---|---|
| Creator | globale Rolle: Umgebungen im Projekt anlegen; nötig, wenn ein YAML-Lauf die Umgebung anlegen soll; Mitwirkende sind standardmäßig Mitglieder |
| Reader | die Umgebung ansehen |
| User | die Umgebung beim Schreiben oder Ändern von YAML-Pipelines benutzen |
| Administrator | Berechtigungen, Anlegen, Verwalten, Ansehen, Benutzen; die Ersteller sind standardmäßig Administratoren; sie können die Umgebung für alle Pipelines öffnen |
Genehmigungen und Prüfungen verwalten laut Microsoft die Rollen Creator, Administrator und User, nicht die Rolle Reader. Rechte sind pro Umgebung über Security einstellbar, auch geerbt und überschrieben. Dazu kommen Pipeline permissions: Standardmäßig darf jede Pipeline eine Umgebung benutzen („offener Zugriff“); mit Restrict permission schränken Sie das ein und erlauben dann einzelne Pipelines mit +. Für Produktionsumgebungen ist das die Grundeinstellung, die Sie wählen.