Änderungen sicher durchführen (PR + CI + CD)¶

Jede Konfigurationsänderung, ob Hub oder Spoke, folgt demselben Vorgehen. Jedes Runbook unter Häufige Anfragen baut darauf auf.

Das Vorgehen¶

1. Die Anfrage erfassen¶

Sammle die Felder der Anfrage, die im Runbook aufgeführt sind. Bewahre die Anfrage (Ticket, Work Item oder Issue) auf und verlinke sie in deinem pull request. Das ist dein Änderungsnachweis.

2. Einen Branch im Konfigurations-Repository erstellen¶

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

3. Die Konfiguration bearbeiten¶

Jede Plattform-Umgebung hat unter environments/ ihren eigenen Ordner. Führe dieselbe Änderung in jedem Umgebungsordner durch, der sie bekommen soll, und wende sie zuerst auf canary an.

Ändere nur die Dateien, die das Runbook nennt. Halte das JSON gültig: zwei Leerzeichen Einrückung, keine abschließenden Kommas, Endung .json.

Note

Dateien, die nicht auf .json enden, werden von jedem Loader ignoriert (/**/*.json, Get-ChildItem -Filter '*.json'). Um eine Datei zu deaktivieren, ohne sie zu löschen, benenne sie in <name>.json.ignore um.

4. Vor dem Push validieren (optional, empfohlen)¶

Führe dieselben Config-Tests aus, die auch die pipeline ausführt (siehe Tests lokal ausführen):

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

5. Einen pull request (PR) öffnen¶

Beschreibe die Änderung, verlinke die Anfrage und bitte einen zweiten Engineer um ein Review. Reviewer prüfen:

dass die Änderung zur Anfrage passt;
dass Namen und Prioritäten eindeutig sind;
dass sich nichts außerhalb der Anfrage geändert hat.

6. Plan gegen canary (CI)¶

Führe die Entry-pipeline von deinem Branch in einem Modus aus, der ohne dich nichts anwendet: Plan oder ApproveModifications (siehe Pipelines und Workflows). Lies den Plan jedes layers:

Erwartet: Nur die im Runbook genannten Ressourcen erscheinen als add oder change.
Stopp, wenn du unerwartete destroy-Aktionen siehst, Änderungen in layers, die das Runbook nicht erwähnt, oder wenn ein ganzer Ordner mit Ressourcen entfernt wird. Ein entfernter Ordner deutet meist auf einen falschen Pfad in den tfvars hin.

7. Auf canary anwenden, verifizieren, dann prod (CD)¶

Genehmige oder wende canary an.
Führe die Verify-Schritte des Runbooks aus.
Lass den Lauf zu prod weiterlaufen oder starte ihn für prod, und prüfe den prod-Plan auf dieselbe Weise.

8. Merge¶

Führe den Merge des pull requests durch, damit main immer beschreibt, was deployt ist. Wenn du vom Branch aus deployt hast, führe den Merge direkt nach einem erfolgreichen apply durch. Sonst macht der nächste Lauf von main deine Änderung rückgängig.

Rollback¶

Die Konfiguration ist deklarativ. Ein Rollback bedeutet daher, Git den alten Zustand beschreiben zu lassen und ihn erneut anzuwenden:

git revert <merge-commit>

Führe dann dieselbe pipeline erneut aus. Manche Ressourcen lassen sich nicht einfach wiederherstellen:

ein gelöschter Key Vault mit purge protection (er wird beim erneuten Erstellen wiederhergestellt, mit seinen alten Secrets)
eine gekündigte subscription
gelöschte Entra ID-Gruppen und Service Principals

Tests lokal ausführen¶

Der Dev Container des Code-Repositorys (.devcontainer/devcontainer.json) enthält die Toolchain, die die pipelines verwenden (PowerShell 7, Terraform 1.14.4, Azure CLI, Pester). Er bindet ../config, relativ zum Code-Repository, unter /workspaces/config ein. Klone dein Konfigurations-Repository neben xms-cloud-platform-code als config.

Öffne das Code-Repository im Dev Container (VS Code: Reopen in Container).

Erstelle .env aus .env.example und setze MCP_CONFIG:

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

Führe die Tests aus:
```
pwsh ./dev/dev.ps1 -Action Test
```

Test führt die Modul-Parity-Checks und Unit-Tests aus und danach die Config-Tests für deine mcp.json: firewall und IP groups, App Gateway, WAF und die DNS-Baseline.

Einen einzelnen layer lokal ausführen¶

Die lokalen Funktionen führen denselben Plan- und Apply-Code wie die pipelines aus, gegen das Environment in MCP_CONFIG, mit deinem eigenen Azure-Login.

dev.ps1 hub- und spoke-Aktionen

Auf main und release/v4.12 wird dev/dev.ps1 -Action HubDeploy (und HubUnlock, SpokeDeploy, …) von seinem ValidateSet abgelehnt, und die spoke-Aktionen sind fest auf eine Demo-Datei verdrahtet. Bis der Fix gemergt ist, rufe die Funktionen direkt auf, wie unten gezeigt. Siehe Bekannte Probleme.

# 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

Funktion	Was sie macht
`Deploy-XebiaLocal`	Plan (und apply, wenn WhatIf aus ist) für hub layers (`-DeployName`, `-Region`) oder Spokes (`-SpokeFilePaths`)
`Remove-XebiaLocal`	Destroy, in umgekehrter layer-Reihenfolge
`Unlock-XebiaLocal`	Eine hängende Terraform-state-Lease aufbrechen

Tip

Nutze lokale Läufe für die Diagnose und für canary. Für prod verwende die pipelines, damit jede Änderung eine Lauf-Historie und eine Genehmigung hat.