Review und Deployment eines Managed-VM-pull-requests¶

Runbook für Reviewer und Operatoren für pull requests, die die Konfiguration von Managed Virtual Machines hinzufügen oder ändern. Es beschreibt, wie du den pull request validierst, welche Einstellungen einen zweiten Blick brauchen, wie du die Modul-pipeline ausführst und wie du mit Fehlern umgehst. Das Modul selbst, die Anfragefelder und die regelmäßigen Prüfungen stehen unter Managed-VM-Modul (Plattformseite). Die Sicht des workload-Teams steht unter Einen Managed-VM-pull-request vorbereiten.

Geltungsbereich¶

Das Runbook gilt für:

pull requests für die Konfiguration von Managed VMs (neue VM-Deployments und Änderungen an bestehenden VM-Konfigurationen);
das Konfigurations-Repository der spokes und des Managed-VM-Moduls;
Entwicklungs-/Test-, Nicht-Produktions- und Produktionsumgebungen.

Das Ziel ist eine konsistente und korrekte Konfiguration und ein sicheres Deployment von virtuellen Maschinen in die spokes.

1. Vorbereitung¶

Stelle sicher, dass du Zugriff auf das Tooling der Plattform (das Repository, die pipelines und das Ticketsystem) und auf das Repository des richtigen Kunden oder der richtigen Plattform-Umgebung hast.

2. Den Stand des pull requests prüfen¶

Prüfung	Aktion, wenn sie fehlschlägt
Der pull request ist kein Entwurf (draft)	Kommentiere im Ticket: Der Anfragende muss ihn zuerst fertigstellen.
Die erforderlichen Checks sind bestanden	Stelle die pipeline erneut in die Warteschlange, wenn das Ergebnis abgelaufen ist. Ist sie fehlgeschlagen, bitte den Anfragenden, es zu beheben, bevor der Review weitergeht.
Alle Kommentare sind aufgelöst	Bitte den Anfragenden, sie aufzulösen.
Ein Ticket ist verknüpft	Verknüpfe es oder mache den Check optional, wenn dein Prozess es erlaubt.
Du kennst den Anfragenden	Er steht unter dem Titel. Richte deine Kommentare an ihn.

Erforderliche Checks hängen von der Plattform ab

Die Validierungs-pipeline als erforderlicher Check ist nicht überall verfügbar. Wo sie fehlt, validiere die Dateien selbst.

3. Die Konfiguration prüfen¶

3.1 Um welche Art von Änderung es geht¶

Finde heraus, ob der pull request eine neue VM-Konfiguration oder eine Änderung an einer bestehenden VM ist: Größe, Tags, Aufbewahrung, Owner, Anzahl der Instanzen und so weiter. Die unterstützten Änderungstypen stehen unter Änderungstypen, die zu einer Standardänderung passen. Alles andere ist keine Standardänderung.

3.2 Dateien und Ordner¶

Die Konfigurationsdatei:

liegt im Ordner des richtigen spokes;
folgt der Namensgebung der Plattform für die Umgebung (zum Beispiel prod, nonprod oder dev);
ist in der pipeline-Konfiguration eingebunden.

Neue Ordner und Dateien müssen in der pipeline referenziert werden

Ein spoke-Ordner, der nicht in der Liste der spokes der Modul-pipeline steht, wird nicht deployt, und die pipeline bleibt grün. Prüfe, dass der pull request die Referenz ergänzt.

3.3 Inhalt¶

Es gibt kein einzelnes Feld, das du für sich prüfst: Alle Variablen müssen vorhanden und korrekt sein. Vergleiche die neue Datei mit einer bestehenden, funktionierenden Konfiguration, mit einem Tool zum Dateivergleich, und stelle sicher, dass alle erwarteten Variablen existieren und korrekt aufgebaut sind. Prüfe diese Punkte per Augenschein:

Die Subscription-ID und die resource group verweisen auf einen bestehenden spoke;
die Version des connectivity-Moduls ist dieselbe wie in bestehenden Deployments (zum Beispiel connectivity_v1);
die Einstellungen für Bastion und Login sind vorhanden;
die Owner sind definiert und sind Personen, die in Entra ID existieren;
die Tags haben das richtige Format, und PatchPriority ist ein gültiger Wert;
die Gesamtlänge von Workload-Kurzname und Konfigurations-Kurzname liegt innerhalb des Limits (Anfragefelder).

3.4 Einstellungen, die einen zweiten Blick brauchen¶

Einstellung	Prüfung
`useAccessPackages`	Kann `true` oder `false` sein. Manche Plattformen nutzen keine Access Packages mehr und bevorzugen `false`. Ist es `true`, frage den Anfragenden, ob das beabsichtigt ist.
`instances`	Anzahl der VMs. Bei einem Wert über 1 werden mehrere VMs mit derselben Konfiguration erstellt, mit den Standardnamen und einem aufsteigenden Suffix. Prüfe, dass die Anzahl die angefragte ist.
Backup	Eine Backup-Lösung muss definiert sein. Der Recovery Services vault ist die bevorzugte, der Backup Vault ist die ältere Option, die weiter unterstützt wird.
Disks	Die Größe der OS-Disk wählt der Kunde. Data Disks sind optional: Fehlende Data Disks sind in Ordnung, solange der Plan nicht fehlschlägt. Wird eine Data Disk entfernt, prüfe den Index (er ist die Position in der Liste) und dass die Daten nicht gebraucht werden.
Größe (SKU)	Eine Größenänderung startet die VM neu. Prüfe die Quota und vereinbare einen Zeitpunkt.

4. Die pipeline ausführen¶

4.1 Welche pipeline¶

Nutze die pipeline Managed VM deployment. Wähle für die Validierung eines pull requests den Branch des pull requests. Für das Deployment nach dem Merge nutze main.

4.2 Welche stage¶

Wähle alle stages ab.
Suche die stage, die zum spoke-Namen und zur Umgebung passt (Entwicklung/Test, Nicht-Produktion, Produktion), und wähle sie aus.
Stelle sicher, dass die stage zum Namen der Konfigurationsdatei passt.

4.3 Deployment-Ablauf¶

Die Build-Phase führt den Terraform-Plan aus. Schlägt sie fehl, sende den Fehler an den Autor des pull requests und bitte um eine Korrektur.
Entwicklung/Test und Nicht-Produktion deployen nach dem Build automatisch.
Produktion wartet auf die Genehmigung eines zweiten Engineers. Lies den Plan noch einmal, bevor du genehmigst.

4.4 Das Apply verifizieren¶

Nachdem die Apply-stage grün ist:

Öffne das Apply-Log.
Prüfe, dass die angefragte Änderung durchgeführt wurde.
Verlasse dich nicht allein auf die grüne stage. Ist die Änderung nicht sichtbar, betrachte das Deployment nicht als erfolgreich. Untersuche es und bitte bei Bedarf einen zweiten Engineer.

5. Abschließender Review und Abschluss¶

Alle Checks in Ordnung: Genehmige den pull request, deploye und verifiziere.
Aktualisiere das Ticket: Schreibe, dass die Änderung deployt ist, weise es dem Anfragenden zu und setze es auf Resolved.
Sage dem Anfragenden, wie er sich verbindet und wo die Credentials liegen (Mit virtuellen Maschinen verbinden).

6. Fehlerbehandlung¶

Problem	Aktion
Der Terraform-Plan schlägt fehl	Sende die Fehlerausgabe an den Anfragenden und bitte um ein Update des pull requests.
Der Fehler ist unklar oder komplex	Frage einen zweiten Plattform-Engineer.
Nichts wird deployt, die pipeline ist grün	Der spoke-Ordner steht nicht in der Modul-pipeline. Füge ihn hinzu.
Der Key-Vault-Name ist falsch	Setze `key_vault_name` explizit (Anfragefelder).