Code¶

Das Code-Repository xms-cloud-platform-code enthält alles, was für jeden Kunden gleich ist. Dieser Abschnitt beschreibt, welche Tools es verwendet, wie es die Plattform provisioniert und wie du neue Funktionalität baust und releast.

Seite	Inhalt
Diese Seite	Welche Tools wir verwenden und wie das Repository aufgebaut ist
Provisioning	Wie provisioniert wird: Infra (Job Runner), Container, Layer pro Umgebung und Region
Releases und Upgrades	Release-Historie, Upgrade-Leitfäden pro Version und das generische Update-Runbook
Deployment-Layer	Die Terraform-Layer, ihre Reihenfolge und ihr State
Spoke canvas	Was ein spoke-Deployment erstellt: Ressourcen, Gruppen, Service-Principal-Zugangsdaten, erforderliche Berechtigungen
Spoke-canvas-Modulreferenz	Inputs, Outputs und Module des spoke-Terraform, nach Zweck gruppiert
Pipelines und Workflows	Jede Entry Pipeline, ihre Parameter, Modi und Genehmigungen
Neue Funktionalität bauen	Module, Tests, Deployment auf dev, Workflow/Pipeline, PR + CI
Releasing	Versionen, Workflow-Schritte, Release Notes und Upgrade-Leitfäden

Welche Tools wir verwenden¶

Tool	Version (auf `main`)	Verwendet für
Terraform	1.14.4 (`src/Dockerfile`)	Alle hub-Layer (`infra/`) und das spoke canvas (`src/Xebia.Mcp/Files/terraform/spoke-canvas/`)
azurerm / azapi providers	Exakte Pins pro Root Module (azurerm 4.60.0 zum Zeitpunkt der Erstellung)	Azure-Ressourcen. Die Pins werden von `scripts/Test-TerraformRootProviderPins.ps1` geprüft.
PowerShell 7 + Modul `Xebia.Mcp`	–	Die gesamte Orchestrierung: Config-Auflösung, Plan-/Apply-/Analyse-Aktionen, Region-Matrix, Tests (`src/Xebia.Mcp`)
Pester	–	Unit-Tests (`*.Unit.Tests.ps1` neben jeder Funktion) und Config-Tests (`src/Xebia.Mcp/Tests/`)
Terraform test	–	Modul-Tests (`infra/modules/<name>/tests/*.tftest.hcl`, mit `mock_provider`)
Bicep	–	Infrastruktur der Job Runner (`src/Xebia.Mcp/Files/bicep/deploy/initialize/`)
Docker	–	Das `mcp`-Image, in dem alle Pipelines laufen (`src/Dockerfile`)
Azure CLI	2.87.0 (Dev Container)	Login und Azure-Operationen aus dem Modul
GitVersion	–	Semantische Versionen aus Branches und Merge-Messages (`.GitVersion.yml`)
lefthook	–	Pre-Commit-Hooks: `terraform validate`, `terraform-docs`, `terraform test` für geänderte Module, Provider-Pin-Check (`lefthook.yml`)
terraform-docs	–	Erzeugt das README jedes Layers
Dev container	–	Dieselbe Toolchain lokal (`.devcontainer/devcontainer.json`)
Azure DevOps Pipelines und GitHub Actions	–	CI/CD. Funktional identisch gehalten.
JSON Schema (draft-07)	–	Validierung von spoke-, firewall-, App-Gateway- und WAF-JSON (`src/Xebia.Mcp/Files/json/`)

Repository-Aufbau¶

xms-cloud-platform-code/
├── infra/
│   ├── deploy/<layer>/        Terraform root module per deployment layer (foundation, connectivity, firewall, …)
│   ├── templates/<name>/      Compositions of modules used by the layers
│   └── modules/<name>/        Single-purpose Terraform modules (firewall, ip_group, application_gateway, policy, …)
├── src/
│   ├── Xebia.Mcp/             PowerShell module with all orchestration logic
│   │   ├── Functions/Public/  Entry functions (Invoke-XebiaHub, Invoke-XebiaSpoke, Invoke-XebiaInfrastructure, …)
│   │   ├── Functions/Private/ Internal helpers (plan/apply/analyse actions, config resolution, tests)
│   │   ├── Files/json/        JSON schemas: spokeschema, firewallschema, appgwschema, wafpolicyschema
│   │   ├── Files/terraform/spoke-canvas/   Terraform for spokes (deploy/subscription, deploy/spoke, modules)
│   │   ├── Files/bicep/deploy/initialize/  Bicep for the job runner infrastructure
│   │   └── Tests/             Config tests (Config, SpokeConfig, Smoke)
│   └── Dockerfile             The "mcp" container image
├── .azure-devops/pipelines/   Azure DevOps entry pipelines and templates/ (stage-*, job-*, step-*)
├── .github/workflows/         GitHub Actions entry workflows and reusable stage-*/job-*/step-* workflows
├── .github/actions/           Composite actions (checkout-mcp-code, git-version, terraform-plan/apply, …)
├── dev/dev.ps1                Local entry point (same functions the pipelines call)
├── config/Demo/canary/        Demo configuration used to develop and test the code
├── scripts/                   Helper scripts (provider pin check, terraform test runner, version-watcher)
└── docs/                      ADRs, coding standards, how-tos

Punkte, die sich aus dem Aufbau nicht von selbst ergeben:

Das hub-Terraform läuft aus dem Modul heraus. Vor einem Lauf wird infra/ nach src/Xebia.Mcp/Files/terraform/cloud-platform/ kopiert (Sync-XebiaInfraToMcpModule). Sowohl der Container-Build als auch dev/dev.ps1 tun das, und der Pfad steht in .gitignore. Die Plan-Aktion führt Terraform aus terraform/cloud-platform/deploy/<layer> aus.
Das spoke-Terraform liegt nur im Modul (src/Xebia.Mcp/Files/terraform/spoke-canvas/), nicht in infra/.
YAML bleibt schlank. Pipelines rufen Invoke-XebiaHub, Invoke-XebiaSpoke, Invoke-XebiaInfrastructure und Invoke-XebiaContainer mit einer -Action auf (Prepare, Plan, Analyse, Apply, Clean). Siehe ADR-0011.
Öffentliche Funktionen sind nach Domäne gruppiert unter Functions/Public/: Actions, AzCli, Config, Invocation, Local, Logging, Terraform, Test, Tools, Workflow. (CONTRIBUTING.md erwähnt noch einen Ordner Runner/, den es nicht mehr gibt.)