Zum Inhalt

Einen Managed-VM-Pull-Request vorbereiten

Wenn dein Plattform-Team dir Zugriff auf das Konfigurations-Repository gegeben hat, kannst du eine Änderung an deinen Managed VMs selbst als pull request vorbereiten, statt ein Anfrageformular auszufüllen. Das Plattform-Team prüft, merged und deployt sie weiterhin. Diese Seite zeigt, was du vorbereitest, was der Reviewer prüft und was du erwarten kannst.

Frag dein Plattform-Team, ob dir dieser Weg offensteht. Die Felder und ihre Bedeutung stehen unter Anfragen und Änderungen. Das Runbook des Reviewers ist Review von Managed-VM-Pull-Requests.

Was du tust

  1. Öffne ein Ticket für die Änderung und notiere die Nummer. Das Ticket ist der Änderungsnachweis. Der pull request verweist darauf.
  2. Erstelle einen Branch von main im Konfigurations-Repository.
  3. Bearbeite die VM-Konfigurationsdatei deines Spokes und deiner Umgebung. Es gibt eine Datei pro Spoke und Umgebung. Für einen neuen Spoke startest du mit der Template-Datei der Umgebung oder kopierst eine funktionierende Datei und passt sie an.
  4. Öffne einen pull request auf main. Gib ihm einen Titel und eine Beschreibung, die sagen, welcher Spoke, welche VM-Konfiguration und welche Änderung gemeint ist, und verlinke das Ticket.
  5. Warte auf die Checks. Die Validierungs-pipeline scannt den Code, validiert ihn und plant die Änderung. Behebe, was sie meldet, und pushe erneut. Sie läuft dann von selbst noch einmal.
  6. Bitte um das Review: Schreibe einen Kommentar im Ticket, dass der pull request bereit ist.
  7. Schließe den pull request nicht selbst ab. Das Plattform-Team merged ihn und deployt.

Ein neuer Spoke-Ordner

Die Modul-pipeline deployt nur die Spokes, die in ihrer Liste stehen. Bei einem neuen Ordner bitte das Plattform-Team, den Spoke in diese Liste aufzunehmen, und erwähne das im Ticket. Ohne den Eintrag wird nichts deployt, und die pipeline bleibt grün.

Was der Reviewer prüft

Wenn du die Checks kennst, sparst du dir eine Runde.

Check Worauf der Reviewer achtet
Zustand des pull request Er ist kein Draft, die Checks sind bestanden, es gibt keine Konflikte und alle Kommentare sind gelöst.
Datei und Ordner Die Datei liegt im Ordner des richtigen Spokes, folgt der Namensgebung der Umgebung und steht in der pipeline-Liste.
Bestehender Spoke Subscription und Resource Group gehören zu einem bestehenden Spoke.
Vollständigkeit Alle Variablen sind vorhanden und korrekt aufgebaut. Der Reviewer vergleicht deine Datei mit einer funktionierenden.
Hub-Anbindung Die Connectivity-Version ist dieselbe wie in den bestehenden Deployments.
Zugriff und Owners Bastion- und Login-Einstellungen sind vorhanden. Owners sind definiert und existieren in Entra ID.
Tags Die Tags sind korrekt aufgebaut, und PatchPriority hat einen gültigen Wert.
Namen Workload-Kurzname und Konfigurations-Kurzname zusammen sind nicht zu lang.
Access Packages Wenn du sie auf true setzt, fragt der Reviewer eventuell nach, ob du das willst. Manche Plattformen setzen sie lieber nicht ein.
Instanzen Die Anzahl entspricht deiner Anfrage. Ein Wert über 1 erzeugt mehrere VMs mit derselben Konfiguration und nummerierten Namen.
Backup Eine Backup-Lösung ist definiert. Bevorzugt wird der Recovery Services vault.
Disks Die Größe der OS-Disk ist deine Wahl. Daten-Disks sind optional. Eine entfernte Daten-Disk wird anhand der Listenposition geprüft, weil sich die Positionen der anderen Disks verschieben.
Größe Eine neue Größe startet die VM neu. Der Reviewer prüft das Kontingent und ob du einen Zeitpunkt vereinbart hast.

Erlaubte Änderungen

Das sind normale, gültige Änderungen einer VM-Konfiguration:

  • eine neue VM-Konfiguration;
  • eine neue Größe (SKU);
  • eine Änderung der Tags;
  • eine Änderung der Aufbewahrung oder des Backups;
  • eine Änderung der Owners;
  • eine Änderung der Instanzanzahl;
  • Access Packages ein- oder ausschalten.

Alles andere, zum Beispiel eine neue Option des Moduls oder ein anderes Image, das noch nicht angeboten wird, ist eine Änderung des Moduls und läuft über das Plattform-Team (Support).

Nach dem Merge

Das Plattform-Team führt die pipeline für den richtigen Spoke und die richtige Umgebung aus. Entwicklungs-, Test- und Nicht-Produktionsumgebungen werden normalerweise nach dem Build deployt, Produktion nach einer Genehmigung. Du bekommst eine Nachricht im Ticket, wenn das Deployment abgeschlossen und verifiziert ist. Prüfe dann:

Wenn der Plan fehlschlägt

Das Plattform-Team schickt dir den Fehler. Typische Ursachen sind eine fehlende Variable, ein falsches Format, ein zu langer Name oder eine Größe, die in der Region oder in deinem Kontingent nicht verfügbar ist (Kontingent- und Kapazitätsprobleme). Korrigiere die Datei in deinem Branch und pushe sie.