Generisches Update-Runbook

Der Update-Ablauf für eine Plattformversion auf einer Seite: Voraussetzungen, die Reihenfolge der Schritte und eine Checkliste. Sie beschreibt auch das ältere Layout mit einer einzelnen pipeline, in dem eine pipeline Umgebung, Region und Layer als Laufparameter erhält. Für Repositories mit den aktuellen Entry-pipelines (hub, spoke, infrastructure, container) ist das ausführliche Vorgehen Was zu tun ist, wenn eine neue Version veröffentlicht wird.

Voraussetzungen

Bevor du anfängst, stelle sicher, dass du Folgendes hast:

• ein Work Item, das die Zielversion nennt, geplant in einem Sprint oder Änderungsfenster;
• die Zielversion im Code-Repository (tag oder release-Branch), auf das das Kunden-Repository zeigt (Release-Stand heute);
• Zugriff auf das Konfigurations-Repository (Azure DevOps oder GitHub) und auf den Azure-Tenant im Portal;
• erhöhten Zugriff (PIM), wenn ein Leitfaden Änderungen im Portal verlangt, etwa das Entfernen von Policy-Zuweisungen oder initiatives;
• ein Fenster, das den workload-Teams angekündigt wurde (Wartungskalender).

Der Ablauf

flowchart LR
    a["1. Current version"] --> b["2. Upgrade guides"] --> c["3. Permissions"] --> d["4. Branch + guide steps + bump"]
    d --> e["5. Canary"] --> f["6. Prod"] --> g["7. Merge + validate"]

1. Prüfe die aktuelle Version. Öffne die Entry-pipeline des Konfigurations-Repositorys (main.yaml im älteren Layout oder jede Entry-pipeline im aktuellen Layout), finde die Code-Version, auf die sie zeigt, und schreibe sie auf. Nutzt der Kunde GitHub statt Azure DevOps, mache dasselbe in den Workflow-Dateien, die main.yaml ersetzen.
2. Lies die Upgrade-Leitfäden. Beginne mit dem Leitfaden für die Version direkt nach der aktuellen Version und mache weiter, bis die Zielversion erreicht ist. Folge allen Schritten jedes Leitfadens der Reihe nach. Siehe die Upgrade-Leitfäden der Plattform. Gibt es für eine Version keinen Leitfaden, ist dafür nichts Besonderes nötig.
3. Beantrage Berechtigungen. Bitte um PIM-Elevation (Owner, Contributor oder eine andere Rolle), wenn die Leitfäden sie brauchen, und warte auf die Genehmigung, bevor du etwas änderst.
4. Bereite die Änderung vor. Erstelle einen Branch, zum Beispiel users/<initials>/update-to-v<version>. Führe die Schritte im Konfigurations- Repository und das Aufräumen im Portal aus den Leitfäden durch. Ändere dann die Versionsreferenz:
   • Azure DevOps: in pipelines/main.yaml, der repository resource des Code-Repositorys: setze ref: auf refs/tags/v<version> (oder die tag-Form, die deine Datei bereits nutzt).
   • GitHub: in .github/workflows/main.yaml setze das ref: des checkout-Schritts des Code-Repositorys und ändere das @<version> am Ende beider Reusable-Workflow-Referenzen (canary und prod) auf die neue Version.
5. Führe canary aus. Führe die pipeline für canary Layer für Layer aus (siehe unten). Lies jeden Plan.
6. Führe prod aus. Wiederhole es mit denselben Schritten aus dem Leitfaden. Nutze die validierte canary-Konfiguration. Mache prod-spezifische Änderungen nur, wo der Leitfaden es sagt.
7. Merge und validiere. Erstelle einen pull request, reviewe ihn und merge nach main. Führe das vollständige Deployment noch einmal von main aus und prüfe, dass es keine Änderungen plant. Bestätige die Version im Repository und dass canary und prod gesund sind. Halte Folgeaktionen und Ausnahmen im Work Item fest.

Layer-Reihenfolge im Layout mit einer einzelnen pipeline

Die ältere pipeline fragt drei Laufparameter ab:

Parameter	Wert für das Update
Environment	Zuerst Canary, dann Prod
Region	Die primäre Region der Plattform (wiederhole es für jede weitere Region, die du deployst)
Layer	Ein Layer pro Lauf, in der Reihenfolge unten

Reihenfolge	Layer	Hinweis
1	foundation
2	connectivity
3	ghrunners	Nur, wenn der Kunde von GitHub gehostete runner nutzt
4	identity
5	management
6	firewall
7	postdeployment

Die älteren Runbooks weichen darin ab, wo ghrunners steht (vor oder nach connectivity). Die Reihenfolge oben ist die aus Was zu tun ist, wenn eine neue Version veröffentlicht wird. Prüfe die Reihenfolge gegen die Layer-Abhängigkeiten deiner Version.

Prüfe bei jedem Lauf den Plan, bevor du genehmigst. Enthält der Plan destroys oder replacements, finde heraus, ob sie erwartet sind (der Leitfaden oder die Release Notes sollten sie erwähnen). Bist du unsicher, frage das Produktteam der Plattform, bevor du apply ausführst.

Wenn alle Layer für canary und prod fertig sind und der Branch gemerged ist, führe die pipeline noch einmal von main aus mit Environment all, Region all und Layer all und prüfe auf unerwartete Änderungen.

Aktuelles Layout

Die aktuelle hub-pipeline führt alle Layer in einem Lauf in fester Reihenfolge aus und plant jeden Layer. Siehe Deployment-Layer und Pipelines und Workflows. Der Layer ghrunners gehört nicht zur aktuellen hub-pipeline.

Hinweise

• Release-spezifische Leitfäden sind kumulativ, wenn du mehrere Versionen überspringst.
• Verlangt ein Leitfaden Aufräumen im Portal, mache es vor den späteren Schritten.
• Halte das Konfigurations-Repository im Einklang mit dem, was du deployst. Ein version pin, der sich zwischen Entry-Dateien unterscheidet, ist ein Befund, den du zuerst klären musst.

Checkliste

• [ ] Work Item mit Zielversion, Fenster angekündigt
• [ ] Aktuelle Version festgehalten
• [ ] Jeder Leitfaden zwischen aktueller und Zielversion gelesen und umgesetzt
• [ ] Berechtigungen organisiert
• [ ] Versionsreferenz überall geändert, wo sie vorkommt
• [ ] canary Layer für Layer ausgeführt, Pläne geprüft
• [ ] prod Layer für Layer ausgeführt, Pläne geprüft
• [ ] Nach main gemerged; ein vollständiger Lauf von main plant keine Änderungen
• [ ] Ergebnis und Ausnahmen festgehalten