Pull-Request-Review für Konfigurationsänderungen¶

Jede Änderung am Konfigurations-Repository läuft über einen pull request (PR) und ein zweites Paar Augen (Änderungen sicher durchführen). Diese Seite gibt Autor und Reviewer eine gemeinsame Checkliste. Sie gilt für das Plattform-Team in beiden Betriebsmodellen und für workload-Teams, wenn deine Plattform ihnen erlaubt, Änderungen vorzubereiten (zum Beispiel firewall-Regeln).

Die Schritt-für-Schritt-Runbooks für jede Art von Änderung (was du öffnest, was du prüfst, wie du deployst und wie du das Ticket abschließt) stehen unter Reviewer- und Operator-Runbooks. Diese Seite enthält die Prüfpunkte, die für jeden pull request gelten.

Wer macht was¶

Schritt	Wer	Hinweise
Die Änderung vorbereiten und den PR öffnen	Der Anfragende oder das Plattform-Team im Auftrag des Anfragenden	Wenn das Plattform-Team sie für ein workload-Team vorbereitet, füge den Owner des workloads als Pflicht-Reviewer hinzu und merge nicht, bevor er zugestimmt hat.
Den Inhalt genehmigen	Der Owner des workloads, wo dein Prozess es verlangt	Er bestätigt, dass die Änderung dem entspricht, was er angefragt hat.
Technisch prüfen	Ein Engineer des Plattform-Teams, der die Änderung nicht geschrieben hat	Vier-Augen-Prinzip.
Mergen und deployen	Das Plattform-Team	Der Anfragende schließt seinen eigenen PR nicht ab. Aktiviere kein Auto-Complete bei einer Änderung, die eine separate Genehmigung braucht.

Im managed-service-Modell legt der Vertrag fest, wer genehmigt und wie lange das Deployment dauern darf. Im Eigenbetrieb entscheidet dein eigenes Team. Ein pull request, der die Konfiguration eines workloads ohne Beteiligung und Genehmigung seines Owners ändert, kann abgelehnt werden.

Branch, Titel und Beschreibung¶

Branch-Name: change/<request-id>-<short-description>, wie in Änderungen sicher durchführen.
Titel: Ein festes Muster hilft beim Überfliegen der Liste, zum Beispiel [<WORKLOAD>] <Action> - <short description> (zum Beispiel [APP1] Add firewall rules - database connectivity).
Beschreibung: was die Änderung tut, der workload, der geschäftliche Grund, der Link zur Anfrage und welche Umgebungen betroffen sind. Beschreibe bei firewall-Regeln den Verkehr: von wo, wohin, welcher Port.
Verlinke die Anfrage (Ticket oder Work Item), damit Änderungsdatensatz und Code zusammenbleiben.

Bevor du den Inhalt prüfst¶

Prüfe zuerst den Zustand des pull requests. Ein pull request, der nicht bereit ist, kostet Zeit des Reviewers.

Prüfung	Wenn es nicht in Ordnung ist
Der pull request ist kein Entwurf	Schick ihn zurück: Der Autor stellt ihn zuerst fertig.
Die erforderlichen Prüfungen (die Validierungs-pipeline) sind durchgelaufen	Wenn die Prüfung abgelaufen ist, stelle sie erneut in die Warteschlange. Wenn sie fehlgeschlagen ist, schick den pull request mit dem Fehler zurück.
Es gibt keine Merge-Konflikte	Schick ihn zurück: Der Autor löst sie (Merge-Konflikte lösen).
Alle Kommentare sind gelöst	Schick ihn zurück, bis sie es sind.
Ein Work Item oder Ticket ist verlinkt	Verlinke es. Wenn die Plattform für jeden pull request einen Link verlangt, deiner aber kein Ticket hat, frag nach einem.

Schick ihn zurück jedes Mal auf dieselbe Weise, damit der Autor weiß, was zu tun ist, und nichts verloren geht:

Gehe zum Ticket, das mit dem pull request verlinkt ist.
Erwähne den Autor und schreibe, was nicht stimmt und was sich ändern muss.
Setze das Ticket zurück auf den Status New (oder das Äquivalent in deinem Tooling) und weise es dem Autor zu.

Der Autor korrigiert den pull request und setzt das Ticket wieder weiter (Der Standardänderungsprozess).

Den pull request abschließen¶

Setze auto-complete auf dem pull request nur, wenn keine separate Genehmigung nötig ist, und dann:

schalte complete the linked work items after merging aus, weil das Ticket nach dem verifizierten Deployment gelöst wird, nicht nach dem Merge;
schalte delete the source branch after merging ein.

Der Autor schließt seinen eigenen pull request nicht ab.

Was der Reviewer prüft¶

Jeder PR¶

Die Änderung entspricht der Anfrage, und nichts anderes wurde geändert.
Dieselbe Änderung ist in jedem Ordner einer Plattform-Umgebung gemacht, der sie braucht (zum Beispiel canary und prod), und wird zuerst auf canary angewendet.
Das JSON ist gültig und die Config-Tests laufen durch (pwsh ./dev/dev.ps1 -Action Test, siehe Tests lokal ausführen).
Namen und Prioritäten sind eindeutig und folgen deinem Namensschema.
Der PR ist klein: eine logische Änderung, und bei der firewall eine Rule Collection Group.
Der Plan (nicht nur der Diff) zeigt nur die erwarteten Adds und Changes. Halte bei jedem destroy oder must be replaced an, das niemand erwartet. Ein ganzer Ordner mit Ressourcen, der zerstört wird, deutet meist auf einen falschen Pfad hin.

Firewall-Regeln und IP Groups¶

Das richtige Team besitzt die Datei (siehe Richtlinien für firewall-Regeln und IP Groups).
Es gibt eine canary-Datei und eine prod-Datei mit derselben Änderung (außer die Regel ist nur für eine Umgebung gedacht).
Global oder regional: Die Regel liegt in dem Ordner, der zu ihrem Inhalt passt (Globale oder regionale Regel).
Der Regeltyp passt: Application Rule für Internet-FQDNs, Network Rule für internen Verkehr.
Das Ziel ist so spezifisch wie möglich und die Ports sind exakt. Kein * oder Any ohne schriftlichen Grund.
Pro Regel nur ein Quelltyp und ein Zieltyp. Referenzierte IP Groups existieren: Die Datei ist bereits im Repository oder Teil desselben pull requests, in einem ip_groups-Ordner derselben Plattform-Umgebung (und Region).
Wenn ein Prioritätsfeld geändert wurde: Die NAT-Collections haben eine niedrigere Nummer als die network Collections, und diese eine niedrigere Nummer als die application Collections.
Prioritäten liegen im Bereich des Owners und sind eindeutig.
Wenn eine Regel eine andere ersetzt: Die neue Regel wird zuerst hinzugefügt, und die alte Regel wird in einem späteren PR entfernt.
Wenn eine IP Group umbenannt oder entfernt wird: Die Referenzen werden zuerst geändert, in einem früheren PR.

IP-Group-Dateien¶

Die Datei liegt in einem ip_groups-Ordner, sowohl in canary als auch in prod, und der Name folgt deinem Schema.
cidrs enthält gültige IPv4-Adressen oder CIDR-Bereiche, die für den Zweck vereinbart sind. Keine unzusammenhängenden Subnets in einer Gruppe.
Wenn eine Gruppe umbenannt oder entfernt wird: siehe die Zwei-Schritt-Regel oben.

Siehe Änderung einer IP group.

Spokes¶

workloadShortName und environment eines bestehenden Spokes sind unverändert.
Der Dateiname folgt deiner Konvention und ist über alle Unterordner von spokes/ eindeutig (zum Beispiel canvas_<workload>_<environment>.json).
azureSubscriptionId ist bei einem neuen Spoke mit der bestehenden subscription gefüllt. Wer die subscription erstellt, hängt von deinem Prozess ab (Neuer Spoke).
Storage Account und Key Vault: Der öffentliche Zugriff ist aus (EnablePublicAccess / enablepublicaccess ist false) und der private endpoint ist an (CreatePrivateEndpoint / createprivateendpoint ist true). Wenn nicht, frag den Anfragenden, ob das beabsichtigt ist. Prüfe beim Storage Account außerdem infrastructure_encryption_enabled (true) und allow_nested_items_to_be_public (false).
Es gibt genau einen resourceconfiguration.network-Eintrag für jede Region in targetRegions.primary und targetRegions.additional.
Jeder Subnet-Bereich liegt im Adressraum seines virtuellen Netzwerks, und die Subnets überlappen sich nicht. Nutze bei Bedarf einen Subnet- Rechner.
Jedes Netzwerk hat ein Subnet mit isprivatelinksubnet auf true. Eines ist die Konvention. Der Code nimmt das erste.
Jede in linkednetworksecuritygroupname genannte network security group existiert in networksecuritygroups desselben Netzwerks.
Adressbereiche überlappen sich nicht mit anderen Bereichen im IP-Plan, und der Bereich ist im Plan festgehalten. Der Code prüft keine Überlappungen.
Delegierungen, Service Endpoints und NSG-Regeln entsprechen der Anfrage. Eine bestehende NSG-Regel behält ihre Priorität.
Die Namen der Team-Gruppen existieren in Entra ID.

Application Gateway¶

Jede Referenz (Pool, Setting, Listener, Port, Zertifikat) zeigt auf einen existierenden Key.
Jeder HTTPS-Listener hat ein Zertifikat, und das Zertifikats-Secret existiert im Gateway-Key-Vault.
Der Netzwerkpfad zum Backend ist offen (firewall-Regel und NSG).
Ein Listener und sein Port passen zusammen: Https mit dem HTTPS-Port, Http mit dem HTTP-Port. Prioritäten der Routing-Regeln sind eindeutig.
Bei einer WAF-Policy-Datei: siehe WAF-Policy-Review.

Managed VMs¶

Die Datei liegt im Ordner des richtigen Spokes, folgt der Benennung für die Umgebung, und der Ordner ist in der Modul-pipeline aufgeführt.
Eine neue Datei sieht aus wie eine funktionierende: Vergleiche sie und prüfe, dass alle Variablen vorhanden sind.
Siehe Review von pull requests für Managed VMs.

Policies¶

Zuweisungsnamen sind eindeutig und auf Management-Group-Ebene höchstens 24 Zeichen lang.
Ausnahmen haben eine Genehmigungsreferenz, eine Begründung und ein Enddatum (Policy-Ausnahmen).

Konfiguration löschen¶

Löschen ist der teuerste Fehler, weil es echte Ressourcen zerstört.

Vergleiche vor dem Löschen einer Konfiguration ihren Namen mit den tatsächlichen Ressourcen in Azure. Namen, die eine Umgebung enthalten (zum Beispiel ein Konfigurationssatz namens prd, der eine VM mit prd im Namen baut), sind leicht zu verwechseln. Vermeide Umgebungsnamen in den Namen von Konfigurationselementen und lass eine zweite Person das Ziel bestätigen, bevor der PR gemergt wird.
Bitte den Anfragenden, das Löschen schriftlich mit dem Namen der Ressource zu bestätigen.
Lies den Plan und prüfe, dass nur die vorgesehenen Ressourcen zerstört werden.

Merge-Konflikte lösen¶

Ein Konflikt bedeutet, dass jemand dieselbe Datei geändert hat, nachdem du deinen Branch erstellt hast. Bringe deinen Branch auf den neuesten Stand und löse den Konflikt in deinem eigenen Branch:

git fetch origin
git switch <your branch>
git merge origin/main

Git listet die Dateien mit Konflikten auf. Öffne jede Datei und behalte die Zeilen, die du von beiden Seiten brauchst (ein Editor mit Merge-Ansicht zeigt die eingehende Änderung, deine Änderung und das Ergebnis). Prüfe, dass das JSON noch gültig ist, führe die Config-Tests aus, dann committe und pushe:

git add <resolved files>
git commit
git push

Wie du einen Konflikt löst, hängt von der Änderung ab. Frag eine Kollegin oder einen Kollegen, wenn du nicht sicher bist, was die andere Änderung gemacht hat.

Optional: automatisierte Review-Kommentare¶

Manche Teams fügen dem PR einen pipeline-Schritt hinzu, der den Diff an ein KI-Modell sendet und die Ergebnisse als Kommentare postet. Das kann Fehler früh finden, zum Beispiel einen fehlenden Key oder einen uneinheitlichen Namen. Regeln für die Nutzung:

Behandle die Kommentare als Empfehlung. Sie ersetzen weder das menschliche Review noch die Prüfung des Plans.
Gib dem Modell dieselben Richtlinien, die du einem Menschen gibst, zum Beispiel die Richtlinien für firewall-Regeln und IP Groups, als Teil des Prompts.
Begrenze die Größe des Diffs, den du sendest, und sende keine Secrets oder personenbezogenen Daten.
Gib der pipeline-Identität nur die Berechtigung, die sie zum Posten von Kommentaren braucht.