Platform deploy flow¶

Een platformomgeving wordt in drie stappen uitgerold. Elke stap hangt af van de vorige.

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["Platformomgeving<br/>canary → prod"]
    env --> layers["Layers<br/>foundation … postdeployment"]
    mcp --> spoke["Spokes"]
    spoke --> n["Spoke 1 … N"]

Stap	Pipeline	Wat het doet	Wanneer je het draait
1. Infra	`infrastructure`	Rolt de job runners uit waarop de andere pipelines draaien: virtual network en NAT gateway, Azure Container Registry, Managed DevOps Pool, Container Apps environment, DNS resolver (Bicep in `src/Xebia.Mcp/Files/bicep/deploy/initialize/`). Maakt ook de blob container aan in het hub state storage account.	Eenmalig bij de bootstrap, en wanneer een release de runner-Bicep wijzigt.
2. Release	`container`	Bouwt de `mcp` container image vanuit de vastgepinde codeversie en pusht die naar de ACR. De image bevat PowerShell, Terraform, Azure CLI, de `Xebia.Mcp` module en de hub-Terraform.	Na elke verhoging van de codeversie.
3. MCP	`hub`, daarna `spoke`	Rolt het platform zelf uit, zie hieronder.	Bij elke wijziging.

3a. Hub → platformomgeving → layers¶

De hub pipeline rolt één platformomgeving tegelijk uit: eerst canary, dan prod (de prod stage hangt af van de canary stage in de referentie-hub.yaml). Binnen een platformomgeving draaien de layers in een vaste volgorde:

flowchart LR
    subgraph L1["Level 1: primaire regio"]
        f1[foundation] --> c1[connectivity]
    end
    subgraph L2["Level 2: overige regio's"]
        f2[foundation] --> c2[connectivity]
    end
    subgraph L3["Level 3: alle regio's"]
        fw[firewall]
        id[identity]
        mg[management]
    end
    subgraph L4["Level 4: primaire regio"]
        pd[postdeployment]
    end
    L1 --> L2 --> L3 --> L4

Elke layer wordt gepland, optioneel goedgekeurd, en toegepast vanuit de opgeslagen plan. Details: Deployment layers en Pipelines en workflows.

3b. Spokes 1 … N¶

De spoke pipeline rolt de spoke JSON-bestanden uit die overeenkomen met spokeGlob in één platformomgeving. De spokes worden gegroepeerd per spoke-omgeving en draaien in de volgorde dev → tst → acc → prd. Elke spoke heeft twee Terraform states:

de subscription layer (tags, naam, management group), en
de spoke canvas layer (netwerk, identiteit, Key Vault, storage, Log Analytics).

Spokes zijn afhankelijk van de hub: de virtual hub connection heeft de hub nodig, en de management group moet bestaan. Rol de hub uit vóór de eerste spoke.

Een nieuwe platformomgeving bootstrappen¶

Voor de complete volgorde rond deze tabel (workshop, vereisten, identiteiten, repositories, validatie en overdracht), zie Het platform implementeren. | # | Stap | Wie / wat | |---|---|---| | 0 | Maak de Terraform state storage account(s), de spoke state blob container en de deployment service principal(s) aan, en geef ze toegang | Met de hand, dit zijn vereisten vooraf | | 0 | Maak <env-folder>/mcp.json, global.auto.tfvars en de regio-tfvars aan in de configuratierepository | Config | | 1 | Draai infrastructure | Job runners + hub state container | | 2 | Draai container | mcp image | | 3 | Draai hub (eerst in Plan-modus, daarna Apply) | Hub layers, canary en daarna prod | | 3 | Draai spoke voor elke spoke | Spokes |

Spoke state container

Geen enkele pipeline maakt de blob container voor de spoke state (Azure.TerraformState.Spoke.ContainerName) aan. Maak die met de hand aan vóór de eerste spoke-run, anders mislukt de initialisatie van de backend.

Meer details: Provisioning.