Spoke-pull-request-Review¶

Reviewer-Runbook für pull requests, die eine spoke-Datei erstellen oder ändern. Verwende es zusammen mit den allgemeinen Prüfungen unter Prüfung von pull requests. Die Felder und ihre Bedeutung stehen in der Spoke-JSON-Referenz.

1. Den Zustand des pull requests prüfen¶

Prüfung	Aktion, wenn sie fehlschlägt
Der pull request ist kein Draft	Kommentiere im Ticket: Der Anfragende muss ihn zuerst fertigstellen.
Die erforderlichen Checks sind bestanden	Stelle die pipeline erneut in die Queue, wenn das Ergebnis abgelaufen ist. Wenn sie fehlgeschlagen ist, kommentiere im Ticket und warte auf einen Fix.
Alle Kommentare sind gelöst	Kommentiere im Ticket und warte.
Ein Ticket ist verlinkt	Verlinke es oder mache die Prüfung optional, wenn die Plattform es nicht braucht.

Erforderliche Checks hängen von der Plattform ab

Ob die Validierungs-pipeline im spoke-Repository ein erforderlicher Check ist, hängt von der Plattform ab. Wo es keine gibt, führe die Konfigurationstests selbst aus (Tests lokal ausführen).

Wenn deine Plattform eine Validierungs-pipeline für spoke-Dateien ausführt, prüft sie die Gültigkeit des JSON, das Schema, das Private-Link-Subnetz und den Dateinamen gegen die Umgebung (Spoke-Dateien validieren). Sie ersetzt die folgenden Prüfungen nicht.

Schicke den pull request zurück, wie unter Prüfung von pull requests beschrieben.

2. Jede Datei prüfen¶

Tue das für jede Datei im pull request. Öffne die Ansicht Files.

2.1 Dateiname (neue spokes und wenn sich ein Name geändert hat)¶

Der Dateiname folgt der Konvention deiner Plattform, endet auf .json und ist über alle Unterordner von spokes/ hinweg eindeutig. Viele Plattformen verwenden ein Muster wie canvas_<workload>_<environment>.json. Manche kodieren auch Produktion und Nicht-Produktion im Namen (canvas_prod_..., canvas_nonprod_...). Die Datei muss in einem Unterordner liegen.

2.2 Subscription¶

azureSubscriptionId muss bei einem neuen spoke ausgefüllt sein und eine existierende subscription sein. Wenn sie leer ist, muss die subscription zuerst erstellt werden, nach dem Prozess deiner Organisation (Neuer Spoke). Trage die ID in die Datei ein und committe sie auf den branch.

2.3 Bestehende spokes¶

workloadShortName und environment eines bestehenden spokes sind unverändert. Eine Änderung erzeugt einen neuen State-Key und einen zweiten spoke (Spoke ändern).

2.4 Storage Account und Key Vault (neuer spoke oder wenn sich die Konfiguration geändert hat)¶

Prüfung	Wenn es nicht wie erwartet ist
Storage Account: `EnablePublicAccess` ist `false` und `CreatePrivateEndpoint` ist `true`	Frage den Anfragenden, ob das gewollt ist.
Storage Account: `infrastructure_encryption_enabled` ist `true`	Frage, ob das gewollt ist.
Storage Account: `allow_nested_items_to_be_public` ist `false`	Frage, ob das gewollt ist.
Key Vault: `enablepublicaccess` ist `false` und `createprivateendpoint` ist `true`	Frage, ob das gewollt ist.

2.5 Adressräume (neuer spoke oder wenn sich Adressen geändert haben)¶

Es gibt genau einen resourceconfiguration.network-Eintrag für jede Region in targetRegions.primary und targetRegions.additional.
Jedes Subnet-Präfix (subnets[*].addressPrefix) liegt innerhalb des Adressraums seines Netzwerks (addressPrefix).
Die Subnets überlappen sich nicht. Verwende einen Subnet-Rechner, um sicherzugehen.
Der Bereich überlappt mit keinem anderen Bereich des IP-Plans und ist dort eingetragen. Der Code prüft Überlappungen nicht.

2.6 Subnets (bei Aktualisierung)¶

Jedes Netzwerk hat ein Subnet mit isprivatelinksubnet auf true. Eines ist die Konvention.
Delegierungen sind Namen aus der Liste des Schemas. Service Endpoints sind wie angefragt.

2.7 Network security groups¶

Jede network security group, die ein Subnet in linkednetworksecuritygroupname nennt, muss auch in der networksecuritygroups-Liste desselben Netzwerks existieren. Wenn nicht, bitte den Anfragenden, sie hinzuzufügen. Eine bestehende NSG-Regel behält ihre Priorität (Spoke ändern).

2.8 Identität und tags¶

Die Gruppen in adInfo.ProductTeamGroupNames existieren in Entra ID.
PIMGroupConfig hat pro Rolle einen gültigen Modus (nopim, self-approve, approval).
Die tags enthalten owner, department, workload, pii, costcentre und environment.
Die management group (managementGroupId) passt zur Nutzungsart: Produktionsdaten, personenbezogene Daten und Exposition ins Internet.

3. Abschließendes Review¶

Setze Auto-complete, falls nicht gesetzt, mit resolve work item after merging aus und delete source branch an.
Alle Checks in Ordnung: Genehmige den pull request und deploye (Spoke-Deployment).
Etwas stimmt nicht: Gib klares Feedback und bitte um Änderungen.

2.9 Extensions (bei Änderung)¶

Eine Extension ist nur dann enabled, wenn der Shared-Dienst in shared_services existiert und der Workload ihn braucht (Spoke extensions).
Der Plan nach der Änderung zeigt die Rollenzuweisungen und Gruppen der Extension und keine Löschungen.