Veilig een wijziging doorvoeren (PR + CI + CD)¶

Elke configuratiewijziging, hub of spoke, volgt dezelfde procedure. Elk runbook onder Veelvoorkomende aanvragen bouwt hierop voort.

De procedure¶

1. Leg de aanvraag vast¶

Verzamel de aanvraagvelden die in het runbook staan. Bewaar de aanvraag (ticket, work item of issue) en link ernaar vanuit je pull request. Dit is je wijzigingsrecord.

2. Maak een branch in de configuratierepository¶

git checkout main
git pull
git checkout -b change/<ticket-id>-<short-description>

3. Bewerk de configuratie¶

Elke platformomgeving heeft een eigen map onder environments/. Voer dezelfde wijziging door in elke omgevingsmap die haar moet krijgen, en pas haar eerst toe op canary.

Wijzig alleen de bestanden die het runbook noemt. Houd JSON geldig: inspringing van twee spaties, geen trailing commas, extensie .json.

Note

Bestanden die niet op .json eindigen worden door elke loader genegeerd (/**/*.json, Get-ChildItem -Filter '*.json'). Om een bestand uit te schakelen zonder het te verwijderen, hernoem je het naar <name>.json.ignore.

4. Valideer voordat je pusht (optioneel, aanbevolen)¶

Draai dezelfde config tests als de pipeline (zie De tests lokaal draaien):

$env:MCP_CONFIG = '/workspaces/config/environments/canary/mcp.json'
pwsh ./dev/dev.ps1 -Action Test

5. Open een pull request (PR)¶

Beschrijf de wijziging, link de aanvraag en vraag een tweede engineer om te reviewen. Reviewers controleren:

of de wijziging overeenkomt met de aanvraag;
of namen en prioriteiten uniek zijn;
of er niets buiten de aanvraag is gewijzigd.

6. Plan tegen canary (CI)¶

Draai de entry pipeline vanaf je branch in een modus die niet zonder jou toepast: Plan of ApproveModifications (zie Pipelines en workflows). Lees de plan van elke layer:

Verwacht: alleen de resources die in het runbook genoemd worden verschijnen als add of change.
Stop als je onverwachte destroy-acties ziet, wijzigingen in layers die het runbook niet noemt, of een hele map met resources die wordt verwijderd. Een verwijderde map betekent meestal een verkeerd pad in tfvars.

7. Toepassen op canary, verifiëren, en daarna prod (CD)¶

Keur canary goed of pas het toe.
Doe de Verify-stappen uit het runbook.
Laat de run doorlopen naar prod, of start hem voor prod, en review de prod plan op dezelfde manier.

8. Merge¶

Merge de pull request zodat main altijd beschrijft wat er is gedeployed. Als je vanaf de branch hebt gedeployed, merge dan direct na een geslaagde apply. Anders draait de volgende run vanaf main je wijziging terug.

Rollback¶

De configuratie is declaratief, dus terugdraaien betekent dat je Git de oude staat laat beschrijven en die opnieuw toepast:

git revert <merge-commit>

Draai daarna dezelfde pipeline opnieuw. Sommige resources kunnen niet zomaar terugkomen:

een verwijderde Key Vault met purge protection (die wordt bij opnieuw aanmaken hersteld, met de oude secrets)
een geannuleerde subscription
verwijderde Entra ID-groepen en service principals

De tests lokaal draaien¶

De dev container van de coderepository (.devcontainer/devcontainer.json) bevat de toolchain die de pipelines gebruiken (PowerShell 7, Terraform 1.14.4, Azure CLI, Pester). Deze mount ../config, relatief ten opzichte van de coderepository, op /workspaces/config. Clone je configuratierepository naast xms-cloud-platform-code als config.

Open de coderepository in de dev container (VS Code: Reopen in Container).

Maak .env aan op basis van .env.example en zet MCP_CONFIG:

MCP_CONFIG=/workspaces/config/environments/canary/mcp.json

Draai de tests:
```
pwsh ./dev/dev.ps1 -Action Test
```

Test draait de module parity checks en unit tests, en daarna de config tests voor je mcp.json: firewall en IP groups, App Gateway, WAF en de DNS-baseline.

Eén layer lokaal draaien¶

De lokale functies draaien dezelfde plan- en apply-code als de pipelines, tegen de omgeving in MCP_CONFIG, met je eigen Azure-login.

dev.ps1 hub- en spoke-acties

Op main en release/v4.12 wordt dev/dev.ps1 -Action HubDeploy (en HubUnlock, SpokeDeploy, …) afgewezen door de ValidateSet, en de spoke-acties zijn hard-coded op één Demo-bestand. Roep tot de fix is gemerged de functies direct aan, zoals hieronder getoond. Zie Bekende problemen.

# In the dev container, from the root of xms-cloud-platform-code
Import-Module ./src/Xebia.Mcp/Xebia.Mcp.psd1 -Force
Initialize-XebiaDotEnv
Sync-XebiaInfraToMcpModule -Mappings @(@{ Description = 'cloud-platform'; Source = './infra'; Target = 'terraform/cloud-platform/' }) -WhatIf:$false
$config = Resolve-XebiaMcpConfiguration -Path $env:MCP_CONFIG

# Plan only the firewall layer in gwc (WhatIf on = no apply)
$global:WhatIfPreference = $true
Deploy-XebiaLocal -Config $config -DeployName firewall -Region gwc

# Plan and apply it
$global:WhatIfPreference = $false
Deploy-XebiaLocal -Config $config -DeployName firewall -Region gwc

# Plan one spoke (path relative to <env-folder>/spokes/)
$global:WhatIfPreference = $true
Deploy-XebiaLocal -Config $config -SpokeFilePaths @('team-a/canvas_app1_dev.json')

# Release a stuck state lease
Unlock-XebiaLocal -Config $config -DeployName firewall -Region gwc

Functie	Wat het doet
`Deploy-XebiaLocal`	Plan (en apply als WhatIf uit staat) van hub layers (`-DeployName`, `-Region`) of spokes (`-SpokeFilePaths`)
`Remove-XebiaLocal`	Destroy, in omgekeerde layervolgorde
`Unlock-XebiaLocal`	Doorbreekt een vastzittende Terraform state lease

Tip

Gebruik lokale runs voor diagnose en voor canary. Gebruik voor prod de pipelines, zodat elke wijziging een runhistorie en een goedkeuring heeft.