Generiek update-runbook

De updateflow voor een platformversie op één pagina: vereisten, de volgorde van de stappen en een checklist. Het beschrijft ook de oudere indeling met één pipeline, waarin één pipeline de omgeving, regio en layer als run-parameters meekrijgt. Voor repositories met de huidige entry pipelines (hub, spoke, infrastructure, container) staat de gedetailleerde procedure in Wat te doen als een nieuwe versie wordt gereleased.

Vereisten

Zorg voordat je begint voor:

• een work item dat de doelversie noemt, ingepland in een sprint of wijzigingsvenster;
• de doelversie beschikbaar in de coderepository (tag of releasebranch) waar de klantrepository naar verwijst (Releasestatus nu);
• toegang tot de configuratierepository (Azure DevOps of GitHub) en tot de Azure-tenant in de portal;
• verhoogde toegang (PIM) als een handleiding om wijzigingen in de portal vraagt, zoals het verwijderen van policy-toewijzingen of initiatives;
• een venster dat aan de workload teams is aangekondigd (Onderhoudskalender).

De flow

flowchart LR
    a["1. Current version"] --> b["2. Upgrade guides"] --> c["3. Permissions"] --> d["4. Branch + guide steps + bump"]
    d --> e["5. Canary"] --> f["6. Prod"] --> g["7. Merge + validate"]

1. Controleer de huidige versie. Open de entry pipeline van de configuratierepository (main.yaml in de oudere indeling, of elke entry pipeline in de huidige indeling), zoek de codeversie waar die naar verwijst en schrijf die op. Gebruikt de klant GitHub in plaats van Azure DevOps, doe dan hetzelfde in de workflowbestanden die main.yaml vervangen.
2. Bekijk de upgradehandleidingen. Begin met de handleiding voor de versie net na de huidige versie en ga door tot de doelversie. Volg alle stappen van elke handleiding in volgorde. Zie de upgradehandleidingen voor het platform. Heeft een versie geen handleiding, dan is er niets bijzonders nodig.
3. Vraag permissies aan. Vraag PIM-verhoging aan (Owner, Contributor of een andere rol) als de handleidingen dat nodig hebben, en wacht op goedkeuring voordat je iets wijzigt.
4. Bereid de wijziging voor. Maak een branch, bijvoorbeeld users/<initials>/update-to-v<version>. Doe de stappen in de configuratie- repository en het opruimwerk in de portal uit de handleidingen. Wijzig daarna de versieverwijzing:
   • Azure DevOps: zet in pipelines/main.yaml, bij de repository resource van de coderepository, ref: op refs/tags/v<version> (of de tagvorm die je bestand al gebruikt).
   • GitHub: zet in .github/workflows/main.yaml de ref: van de checkout-stap van de coderepository, en wijzig de @<version> aan het eind van beide verwijzingen naar reusable workflows (canary en prod) naar de nieuwe versie.
5. Draai canary. Draai de pipeline voor canary, layer voor layer (zie hieronder). Lees elk plan.
6. Draai prod. Herhaal met dezelfde handleidingstappen. Gebruik de gevalideerde canary-configuratie. Maak alleen prod-specifieke wijzigingen waar de handleiding dat zegt.
7. Merge en valideer. Maak een pull request, review die en merge naar main. Draai de volledige deployment nog een keer vanaf main en controleer dat er geen wijzigingen worden gepland. Bevestig de versie in de repository, en dat canary en prod gezond zijn. Leg vervolgacties en uitzonderingen vast op het work item.

Volgorde van de layers in de indeling met één pipeline

De oudere pipeline vraagt om drie run-parameters:

Parameter	Waarde voor de update
Environment	Eerst Canary, daarna Prod
Region	De primaire regio van het platform (herhaal voor elke andere regio die je uitrolt)
Layer	Eén layer per run, in de onderstaande volgorde

Volgorde	Layer	Opmerking
1	foundation
2	connectivity
3	ghrunners	Alleen als de klant GitHub-hosted runners gebruikt
4	identity
5	management
6	firewall
7	postdeployment

De oudere runbooks verschillen over waar ghrunners komt (voor of na connectivity). De bovenstaande volgorde is die uit Wat te doen als een nieuwe versie wordt gereleased. Controleer de volgorde aan de hand van de layer-afhankelijkheden van jouw versie.

Bekijk bij elke run het plan voordat je goedkeurt. Bevat het plan destroys of replacements, zoek dan uit of ze verwacht zijn (de handleiding of de release notes hoort ze te noemen). Weet je het niet zeker, vraag dan het productteam van het platform voordat je de apply doet.

Zijn alle layers klaar voor canary en prod en is de branch gemerged, draai de pipeline dan nog een keer vanaf main met environment all, region all en layer all, en controleer op onverwachte wijzigingen.

Huidige indeling

De huidige hub pipeline draait alle layers in één run, in een vaste volgorde, en plant elke layer. Zie Deployment layers en Pipelines en workflows. De layer ghrunners maakt geen deel uit van de huidige hub pipeline.

Opmerkingen

• Releasespecifieke handleidingen zijn cumulatief als je meerdere versies overslaat.
• Vraagt een handleiding om opruimwerk in de portal, doe dat dan vóór de latere stappen.
• Houd de configuratierepository in lijn met wat je deployt. Een versiepin die tussen entry-bestanden verschilt, is een bevinding die je eerst oplost.

Checklist

• [ ] Work item met doelversie, venster aangekondigd
• [ ] Huidige versie vastgelegd
• [ ] Elke handleiding tussen de huidige en de doelversie gelezen en uitgevoerd
• [ ] Permissies geregeld
• [ ] Versieverwijzing overal gewijzigd waar die voorkomt
• [ ] Canary layer voor layer gedraaid, plannen gereviewd
• [ ] Prod layer voor layer gedraaid, plannen gereviewd
• [ ] Gemerged naar main; een volledige run vanaf main plant geen wijzigingen
• [ ] Resultaat en uitzonderingen vastgelegd