Repo-opzet¶
Het platform is verdeeld over twee soorten Git-repository: code en config.
flowchart LR
code["Code<br/>xms-cloud-platform-code<br/>één voor alle klanten"]
config["Config<br/>één per klant<br/>bijv. xms-cloud-platform-config"]
config -- "pins release/vX.Y<br/>(entry pipelines)" --> code
code -. "Layers lezen<br/>waarden uit" .-> config
| Coderepository | Configuratierepository | |
|---|---|---|
| Naam | xms-cloud-platform-code |
Eén per klant, bijvoorbeeld xms-cloud-platform-config (XDEV) |
| Gehost | GitHub Enterprise xebia-managed-services-eu.ghe.com/xmms, gesynct naar de remotes van klanten |
De Azure DevOps of GitHub van de klant |
| Bevat | Terraform layers en modules, de Xebia.Mcp PowerShell-module, JSON-schema's, pipeline templates, de mcp Dockerfile, de Demo-configuratie |
mcp.json, *.auto.tfvars, JSON-bestanden voor firewall, IP groups, App Gateway, WAF, policies en spokes, en de entry pipelines |
| Gewijzigd door | Platformontwikkelaars | Platformoperators. Alle standaardwijzigingen gebeuren hier. |
| Versionering | Releasebranches release/vX.Y, tags vX.Y.Z |
main beschrijft wat is uitgerold |
| Meer lezen | Code | Config |
De configuratierepository bevat geen Terraform. De entry pipelines ervan checken de coderepository uit op een vastgepinde
versie en geven het pad naar een mcp.json mee.
Spoke-bestanden maken deel uit van de configuratierepository (<env-folder>/spokes/), en de Terraform van het spoke canvas maakt deel uit van
de coderepository. Oudere versies gebruikten vier repositories, zie Oudere indelingen.
Hoe code bij klanten komt¶
- Wijzigingen worden gemerged naar
mainvan de coderepository op GitHub Enterprise. - Er wordt een releasebranch
release/vX.Ygemaakt en daarop worden tagsvX.Y.Zaangemaakt. - De
trigger-sync.yamlworkflow draait bij elke push naarmain,release/**env*tags. Die roept dexmms/xms-code-syncdispatcher aan, die de coderepository synct naar de remotes van klanten. - De configuratierepository van de klant pint de versie in de entry pipelines. Zie Versionering.
De repositories opzetten voor een nieuwe klant¶
Maak beide repositories aan in het Azure DevOps-project of de GitHub-organisatie van de klant, breng de gereleasete code binnen en vul de configuratierepository vanuit de template. De stappen, het sync-doel op GitHub en de beveiligingen die je aan het eind inschakelt staan in De repositories voorbereiden.
Twee regels gelden in elke opzet:
- Niemand bewerkt de coderepository op de host van de klant. Die ontvangt alleen gereleasete branches en tags. Maak hem alleen-lezen voor iedereen behalve de sync.
- Alle standaardwijzigingen gebeuren in de configuratierepository, via een pull request. Beveilig de default branch met een verplichte review (een tweede persoon) en beveilig productieruns met een goedkeuringsomgeving.
Werk tijdens de implementatie van het platform op een aparte initial branch van de configuratierepository en merge die
naar main zodra de validatie is geslaagd. Zo beschrijft main altijd een
configuratie die is uitgerold en gecontroleerd.
Oudere indelingen¶
Oudere versies van het platform gebruikten vier repositories: platformcode en platformconfig, plus een spoke canvas-code- en een spoke canvas-configuratierepository. In die indeling
stonden spoke-bestanden in spokes/tfspokes/<workload>/ van de spoke-configuratierepository, en hadden de self-hosted agents een eigen repository. De huidige indeling heeft de twee bovenstaande repositories.
Zie Migreren vanaf een oudere platformversie.
Overige repositories¶
| Repository | Rol |
|---|---|
XMS (Azure DevOps) |
Vorige platformdocumentatie, klantpagina's en runbooks. Wordt vervangen door deze site. |
xms-code-sync |
Dispatcher die de coderepository synct naar de remotes van klanten. |
pdk-docs |
Deze documentatiesite (MkDocs Material). |
De pijl tussen code en config¶
Een layer in de coderepository leest alleen bestanden uit de configuratierepository. Wanneer je een nieuwe feature bouwt, heb je
meestal ook nieuwe configuratie nodig: een nieuwe variabele in een *.auto.tfvars-bestand of een nieuwe JSON-property. Daarom
verwijzen de code- en config-gedeelten van deze site naar elkaar:
- een variabele toevoegen → documenteer die in de hubconfiguratie en de feature flags-referentie;
- een spoke-property toevoegen → werk het schema en de spoke JSON-referentie bij.