Deploy-Ablauf der Plattform¶

Eine Plattform-Umgebung wird in drei Schritten deployt. Jeder Schritt hängt vom vorherigen ab.

flowchart LR
    infra["1. Infra<br/><code>infrastructure</code>"] --> release["2. Release<br/><code>container</code>"]
    release --> mcp["3. MCP"]
    mcp --> hub["Hub"]
    hub --> env["Plattform-Umgebung<br/>canary → prod"]
    env --> layers["Layers<br/>foundation … postdeployment"]
    mcp --> spoke["Spokes"]
    spoke --> n["Spoke 1 … N"]

Schritt	Pipeline	Was sie macht	Wann du sie ausführst
1. Infra	`infrastructure`	Deployt die job runners, auf denen die anderen pipelines laufen: virtual network und NAT Gateway, Azure Container Registry, Managed DevOps Pool, Container-Apps-Umgebung, DNS Resolver (Bicep in `src/Xebia.Mcp/Files/bicep/deploy/initialize/`). Erstellt außerdem den Blob-Container im hub-state-Storage-Account.	Einmal beim Bootstrap und wenn ein release das runner-Bicep ändert.
2. Release	`container`	Baut das Container-Image `mcp` aus der fixierten Code-Version und pusht es in die ACR. Das Image enthält PowerShell, Terraform, Azure CLI, das `Xebia.Mcp` module und das hub-Terraform.	Nach jeder Anhebung der Code-Version.
3. MCP	`hub`, dann `spoke`	Deployt die Plattform selbst, siehe unten.	Bei jeder Änderung.

3a. Hub → Plattform-Umgebung → layers¶

Die pipeline hub deployt jeweils eine Plattform-Umgebung: zuerst canary, dann prod (die prod-Stage hängt in der Referenz-hub.yaml von der canary-Stage ab). Innerhalb einer Plattform-Umgebung laufen die layers in fester Reihenfolge:

flowchart LR
    subgraph L1["Level 1: primäre Region"]
        f1[foundation] --> c1[connectivity]
    end
    subgraph L2["Level 2: andere Regionen"]
        f2[foundation] --> c2[connectivity]
    end
    subgraph L3["Level 3: alle Regionen"]
        fw[firewall]
        id[identity]
        mg[management]
    end
    subgraph L4["Level 4: primäre Region"]
        pd[postdeployment]
    end
    L1 --> L2 --> L3 --> L4

Jeder layer wird geplant, optional genehmigt und aus dem gespeicherten Plan angewendet. Details: Deployment-layers und Pipelines und Workflows.

3b. Spokes 1 … N¶

Die pipeline spoke deployt die spoke-JSON-Dateien, die in einer Plattform-Umgebung auf spokeGlob passen. Die spokes werden nach spoke-Umgebung gruppiert und laufen in der Reihenfolge dev → tst → acc → prd. Jeder spoke hat zwei Terraform states:

den layer subscription (Tags, Name, management group) und
den layer spoke canvas (Netzwerk, Identität, Key Vault, Storage, Log Analytics).

Spokes hängen vom hub ab: Die virtual hub connection braucht den hub, und die management group muss existieren. Deploye den hub vor dem ersten spoke.

Eine neue Plattform-Umgebung bootstrappen¶

Den vollständigen Ablauf rund um diese Tabelle (Workshop, Voraussetzungen, Identitäten, Repositories, Validierung und Übergabe) findest du unter Die Plattform implementieren.

#	Schritt	Wer / was
0	Den oder die Terraform-state-Storage-Accounts, den spoke-state-Blob-Container und den oder die Deployment-Service-Principals erstellen und ihnen Zugriff geben	Von Hand, das sind Voraussetzungen
0	`<env-folder>/mcp.json`, `global.auto.tfvars` und die Region-tfvars im Konfigurations-Repository erstellen	Config
1	`infrastructure` ausführen	Job runners + hub-state-Container
2	`container` ausführen	`mcp`-Image
3	`hub` ausführen (zuerst im Plan mode, dann Apply)	hub-layers, canary dann prod
3	`spoke` für jeden spoke ausführen	Spokes

Spoke-state-Container

Keine pipeline erstellt den Blob-Container für den spoke-state (Azure.TerraformState.Spoke.ContainerName). Erstelle ihn von Hand, bevor du den ersten spoke ausführst, sonst schlägt die Backend-Initialisierung fehl.

Mehr Details: Provisionierung.