Pull request review voor configuratiewijzigingen¶

Elke wijziging aan de configuratierepository gaat via een pull request (PR) en een tweede paar ogen (Veilig een wijziging doorvoeren). Deze pagina geeft de auteur en de reviewer een gedeelde checklist. Ze geldt voor het platformteam in beide beheermodellen, en voor workload teams als je platform hen wijzigingen laat voorbereiden (bijvoorbeeld firewallregels).

De stapsgewijze runbooks voor elk type wijziging (wat je opent, wat je controleert, hoe je deployt en hoe je het ticket sluit) staan in Runbooks voor reviewers en operators. Deze pagina bevat de controles die voor elke pull request gelden.

Wie doet wat¶

Stap	Wie	Opmerkingen
De wijziging voorbereiden en de PR openen	De aanvrager, of het platformteam namens de aanvrager	Bereidt het platformteam het voor een workload team voor, voeg dan de eigenaar van de workload toe als verplichte reviewer en merge niet voordat die goedkeurt.
De inhoud goedkeuren	De eigenaar van de workload, waar je proces dat vereist	Die bevestigt dat de wijziging overeenkomt met wat is aangevraagd.
Technisch reviewen	Een engineer van het platformteam die de wijziging niet heeft geschreven	Vierogenprincipe.
Mergen en deployen	Het platformteam	De aanvrager rondt zijn eigen PR niet af. Zet geen auto-complete aan bij een wijziging die een aparte goedkeuring nodig heeft.

In het managed-servicemodel bepaalt het contract wie goedkeurt en hoe lang deployment mag duren. In het zelfbeheermodel beslist je eigen team. Een pull request die de configuratie van een workload wijzigt zonder betrokkenheid en goedkeuring van de eigenaar kan worden afgewezen.

Branch, titel en beschrijving¶

Branchnaam: change/<request-id>-<short-description>, zoals in Veilig een wijziging doorvoeren.
Titel: een vast patroon helpt bij het scannen van de lijst, bijvoorbeeld [<WORKLOAD>] <Action> - <short description> (bijvoorbeeld [APP1] Add firewall rules - database connectivity).
Beschrijving: wat de wijziging doet, de workload, de zakelijke reden, de link naar de aanvraag en welke omgevingen het raakt. Beschrijf bij firewallregels het verkeer: van waar, naar waar, welke poort.
Link de aanvraag (ticket of work item), zodat het wijzigingsrecord en de code bij elkaar blijven.

Voordat je de inhoud reviewt¶

Controleer eerst de status van de pull request. Een pull request die niet klaar is, kost een reviewer onnodig tijd.

Controle	Als het niet in orde is
De pull request is geen draft	Stuur terug: de auteur maakt hem eerst af.
De verplichte checks (de validatiepipeline) zijn geslaagd	Is de check verlopen, zet hem dan opnieuw in de wachtrij. Is hij mislukt, stuur dan terug met de foutmelding.
Er zijn geen merge conflicts	Stuur terug: de auteur lost ze op (Merge conflicts oplossen).
Alle opmerkingen zijn afgehandeld	Stuur terug totdat ze dat zijn.
Er is een work item of ticket gekoppeld	Koppel het. Eist het platform een koppeling bij elke pull request maar heeft die van jou geen ticket, vraag er dan om.

Stuur terug altijd op dezelfde manier, zodat de auteur weet wat te doen en er niets verloren gaat:

Ga naar het ticket dat aan de pull request is gekoppeld.
Noem de auteur en zeg wat er mis is en wat er moet veranderen.
Zet het ticket terug op de status New (of het equivalent in jouw tooling) en wijs het toe aan de auteur.

De auteur herstelt de pull request en zet het ticket weer verder (Het standaard wijzigingsproces).

De pull request afronden¶

Zet auto-complete op de pull request alleen aan als er geen aparte goedkeuring nodig is, en dan:

zet complete the linked work items after merging uit, omdat het ticket pas wordt opgelost nadat de deployment is gecontroleerd, niet na de merge;
zet delete the source branch after merging aan.

De auteur rondt zijn eigen pull request niet af.

Wat de reviewer controleert¶

Elke PR¶

De wijziging komt overeen met de aanvraag, en er is niets anders gewijzigd.
Dezelfde wijziging is doorgevoerd in elke map van een platformomgeving die haar nodig heeft (bijvoorbeeld canary en prod), en eerst op canary toegepast.
De JSON is geldig en de config tests slagen (pwsh ./dev/dev.ps1 -Action Test, zie De tests lokaal draaien).
Namen en prioriteiten zijn uniek en volgen je naamgevingsschema.
De PR is klein: één logische wijziging, en bij de firewall één rule collection group.
Het plan (niet alleen de diff) toont alleen de verwachte toevoegingen en wijzigingen. Stop bij elke destroy of must be replaced die niemand verwacht. Een hele map met resources die wordt vernietigd duidt meestal op een verkeerd pad.

Firewallregels en IP groups¶

Het juiste team is eigenaar van het bestand (zie Richtlijnen voor firewallregels en IP groups).
Er is een canary-bestand en een prod-bestand, met dezelfde wijziging (tenzij de regel voor één omgeving bedoeld is).
Globaal of regionaal: de regel staat in de map die bij de inhoud past (Globale of regionale regel).
Het regeltype past: application rule voor internet-FQDN's, network rule voor intern verkeer.
De bestemming is zo specifiek mogelijk en de poorten zijn exact. Geen * of Any zonder schriftelijke reden.
Per regel slechts één brontype en één bestemmingstype. Gerefereerde IP groups bestaan: het bestand staat al in de repository, of maakt deel uit van dezelfde pull request, in een ip_groups-map van dezelfde platformomgeving (en regio).
Als een prioriteitsveld is gewijzigd: de NAT-collections hebben een lager nummer dan de network collections, en die een lager nummer dan de application collections.
Prioriteiten liggen binnen het bereik van de eigenaar en zijn uniek.
Als een regel een andere vervangt: de nieuwe regel wordt eerst toegevoegd en de oude regel wordt in een latere PR verwijderd.
Als een IP group wordt hernoemd of verwijderd: de verwijzingen worden eerst aangepast, in een eerdere PR.

IP group-bestanden¶

Het bestand staat in een ip_groups-map, in zowel canary als prod, en de naam volgt je schema.
cidrs bevat geldige IPv4-adressen of CIDR-bereiken die voor het doel zijn afgesproken. Geen niet-gerelateerde subnets in één groep.
Als een groep wordt hernoemd of verwijderd: zie de tweestapsregel hierboven.

Zie IP group-wijziging.

Spokes¶

workloadShortName en environment van een bestaande spoke zijn ongewijzigd.
De bestandsnaam volgt je conventie en is uniek in alle submappen van spokes/ (bijvoorbeeld canvas_<workload>_<environment>.json).
azureSubscriptionId is ingevuld met de bestaande subscription voor een nieuwe spoke. Wie de subscription aanmaakt, hangt af van je proces (Nieuwe spoke).
Storage account en Key Vault: publieke toegang staat uit (EnablePublicAccess / enablepublicaccess is false) en de private endpoint staat aan (CreatePrivateEndpoint / createprivateendpoint is true). Zo niet, vraag de aanvrager of dat de bedoeling is. Controleer voor het storage account ook infrastructure_encryption_enabled (true) en allow_nested_items_to_be_public (false).
Er is precies één resourceconfiguration.network-item voor elke regio in targetRegions.primary en targetRegions.additional.
Elk subnetbereik ligt binnen de adresruimte van het virtuele netwerk, en de subnets overlappen niet. Gebruik zo nodig een subnetcalculator.
Elk netwerk heeft een subnet waarvan isprivatelinksubnet op true staat. Eén is de conventie. De code neemt de eerste.
Elke network security group die in linkednetworksecuritygroupname staat, bestaat in networksecuritygroups van hetzelfde netwerk.
Adresbereiken overlappen niet met een ander bereik in het IP-plan, en het bereik is in het plan vastgelegd. De code controleert geen overlap.
Delegaties, service endpoints en NSG-regels komen overeen met de aanvraag. Een bestaande NSG-regel behoudt zijn prioriteit.
Teamgroepnamen bestaan in Entra ID.

Application Gateway¶

Elke verwijzing (pool, setting, listener, poort, certificate) wijst naar een bestaande sleutel.
Elke HTTPS-listener heeft een certificate, en de certificate-secret bestaat in de Key Vault van de gateway.
Het netwerkpad naar de backend is open (firewallregel en NSG).
Een listener en zijn poort passen bij elkaar: Https met de HTTPS-poort, Http met de HTTP-poort. Prioriteiten van routing rules zijn uniek.
Voor een WAF policy-bestand: zie Review van WAF policy's.

Managed VM's¶

Het bestand staat in de map van de juiste spoke, volgt de naamgeving voor de omgeving, en de map staat in de modulepipeline.
Een nieuw bestand lijkt op een werkend bestand: vergelijk ze en controleer of alle variabelen aanwezig zijn.
Zie Review van pull requests voor managed VM's.

Policies¶

Toewijzingsnamen zijn uniek en maximaal 24 tekens op management group-scope.
Uitzonderingen hebben een goedkeuringsreferentie, een onderbouwing en een einddatum (Policy-uitzonderingen).

Configuratie verwijderen¶

Verwijderen is de duurste fout, omdat het echte resources vernietigt.

Vergelijk voordat je een configuratie verwijdert de naam met de daadwerkelijke resources in Azure. Namen die een omgeving bevatten (bijvoorbeeld een configuratieset prd die een VM met prd in de naam bouwt) zijn gemakkelijk te verwarren. Vermijd omgevingsnamen in de namen van configuratie-items, en laat een tweede persoon het doel bevestigen voordat de PR wordt gemerged.
Vraag de aanvrager het verwijderen schriftelijk te bevestigen, met de naam van de resource.
Lees het plan en controleer dat alleen de bedoelde resources worden vernietigd.

Merge conflicts oplossen¶

Een conflict betekent dat iemand hetzelfde bestand heeft gewijzigd nadat jij je branch had aangemaakt. Breng je branch up-to-date en los het conflict op in je eigen branch:

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

Git toont de conflicterende bestanden. Open elk bestand en behoud de regels die je van beide kanten nodig hebt (een editor met merge-weergave toont de binnenkomende wijziging, jouw wijziging en het resultaat). Controleer dat de JSON nog geldig is, draai de config tests, en commit en push daarna:

git add <resolved files>
git commit
git push

Hoe je een conflict oplost, hangt af van de wijziging. Vraag een collega als je niet zeker weet wat de andere wijziging deed.

Optioneel: geautomatiseerde reviewopmerkingen¶

Sommige teams voegen een pipelinestap aan de PR toe die de diff naar een AI-model stuurt en de bevindingen als opmerkingen plaatst. Dat kan fouten vroeg vinden, bijvoorbeeld een ontbrekende sleutel of een inconsistente naam. Regels voor het gebruik:

Zie de opmerkingen als advies. Ze vervangen de menselijke review en de plancontrole niet.
Geef het model dezelfde richtlijnen die je een mens geeft, bijvoorbeeld de Richtlijnen voor firewallregels en IP groups, als onderdeel van de prompt.
Beperk de omvang van de diff die je verstuurt, en stuur geen secrets of persoonsgegevens mee.
Geef de pipeline-identity alleen de rechten die nodig zijn om opmerkingen te plaatsen.