De repositories voorbereiden¶

Het platform gebruikt twee soorten repository (Repo-opzet): de coderepository, die voor elke klant hetzelfde is, en één configuratierepository per klant. Deze pagina beschrijft hoe je ze inricht in het Azure DevOps-project of de GitHub-organisatie van de klant, hoe de code er komt, en welke beveiligingen je wanneer inschakelt.

Wat je aanmaakt¶

Repository	Naam (voorbeeld)	Inhoud aan het begin	Geschreven door
Code	`xms-cloud-platform-code`	Een kopie van de gereleasete code, ingesynct. Read-only voor het team van de klant.	Alleen de sync
Configuratie	`xms-cloud-platform-config`	Een kopie van de sjabloonconfiguratie (`environments/canary`, `environments/prod`, `pipelines/`, `.github/workflows/`)	Het platformteam

Spoke-bestanden maken deel uit van de configuratierepository (<env-folder>/spokes/). De Terraform van de spoke canvas is onderdeel van de coderepository. Oudere versies gebruikten vier repositories; zie Oudere indelingen.

Waar de repositories staan

Azure DevOps: een privéproject in de organisatie van de klant, met Git-repositories.
GitHub: repositories in de organisatie van de klant, met standaardinstellingen.
In het managed model wordt de coderepository ook op de eigen host van de provider bewaard en gesynct naar de klant. In het zelfbeheermodel sync je een release vanuit de gepubliceerde bron van de provider naar je eigen host en bepaal je zelf wanneer je bijwerkt (Versiebeheer).

1. Maak de repositories aan¶

Azure DevOps¶

Open het project, Repos, New repository. Type Git. Naam: de naam van de coderepository. Herhaal dit voor de configuratierepository.
Clone de configuratierepository. Heeft die nog geen main-branch, maak er dan een met een lege commit en werk voor de implementatie op een aparte branch:
```
git checkout --orphan main
git commit --allow-empty -m "Initial empty commit"
git push -u origin main
git checkout -b initial
```

GitHub¶

Maak beide repositories aan met standaardinstellingen.
Open in de coderepository Settings, Actions, General, Access en sta toegang toe vanuit repositories in de organisatie, zodat de configuratierepository zijn workflows kan gebruiken.
Maak in de configuratierepository main aan met een lege commit en een initial-branch zoals hierboven. Stel de standaardbranch in op initial tijdens de implementatie, en terug op main als de implementatie klaar is.

2. Breng de code binnen¶

De coderepository wordt niet bewerkt op de host van de klant. Hij ontvangt gereleasete versies (branches release/vX.Y en tags vX.Y.Z) vanuit de bron van de provider. Hoe dat werkt, hangt af van het beheermodel:

Managed model. XMMS draait een sync vanuit zijn eigen coderepository. Jij geeft de sync een manier om naar de repository van de klant te schrijven (zie hieronder) en XMMS voegt de repository van de klant toe als doel.
Zelfbeheermodel. Je haalt de release bij de provider op en pusht die zelf naar de coderepository, of zet een gelijkwaardige sync op. Spreek het leveringsmechanisme af met de provider.

Welk mechanisme je ook gebruikt, het resultaat moet zijn: de coderepository op de host van de klant bevat de release- branches en tags die de configuratierepository pint, en niemand anders wijzigt hem.

Doel op GitHub: een GitHub App voor de sync¶

De sync authenticeert als een GitHub App die in de organisatie van de klant is geïnstalleerd. Voor het aanmaken en beheren ervan is de rol App Manager nodig.

Organization settings, Developer settings, GitHub Apps, New GitHub App.
Een naam en beschrijving die zeggen wat hij doet (bijvoorbeeld "repository sync"). Webhook: inactive.
Repository permissions: Contents: read and write, Workflows: read and write.
Waar mag hij worden geïnstalleerd: alleen op dit account.
Noteer na het aanmaken de App ID en genereer een private key (.pem). Bewaar de key in de secret store van de partij die de sync draait, en draag de App ID over.
Installeer de app, kies Only select repositories en selecteer de coderepository (en, in oudere indelingen, de spoke- coderepository). Noteer de installation ID.

De sync ondertekent een tokenaanvraag met de key en wisselt die in voor een kortlevend installation token.

Vergrendel de doelrepository¶

Maak de coderepository read-only voor iedereen behalve de sync, met een ruleset op alle branches die het aanmaken, bijwerken en verwijderen van refs en non-fast-forward pushes blokkeert, en waar de app langs mag.

# Requires the GitHub CLI (gh auth login) and PowerShell 7. Run once per code repository.
$sync_app_id = "<app-id>"
$org         = "<organization>"
$repo        = "xms-cloud-platform-code"
$body = @"
{
  "name": "RO-enforcement",
  "target": "branch",
  "enforcement": "active",
  "conditions": { "ref_name": { "include": ["~ALL"], "exclude": [] } },
  "rules": [
    {"type": "deletion"},
    {"type": "non_fast_forward"},
    {"type": "creation"},
    {"type": "update"}
  ],
  "bypass_actors": [
    { "actor_id": $sync_app_id, "actor_type": "Integration", "bypass_mode": "always" }
  ]
}
"@
$body | gh api --method POST "/repos/$org/$repo/rulesets" --input -

Test de sync nadat je de repository hebt vergrendeld

Draai een sync nadat je de ruleset hebt aangemaakt en controleer dat de app nog kan schrijven. Een ruleset die de sync blokkeert is de gebruikelijke oorzaak van een mislukte eerste sync.

Doel op Azure DevOps¶

De entry pipelines verwijzen naar de coderepository als repository resource (mcp-code). Afhankelijk van de opzet wijst die resource via een service connection naar de host van de provider (de endpoint: in het entry-bestand, zie Versiebeheer), of naar een gesyncte kopie in het eigen project van de klant. Spreek in het tweede geval in de planfase af welke identiteit naar de coderepository schrijft, geef alleen die identiteit schrijfrechten, en blokkeer alle andere schrijvers met een branch policy.

3. Vul de configuratierepository¶

Kopieer het sjabloon naar de configuratierepository op de initial-branch. Het sjabloon is de Demo-configuratie in de coderepository (config/Demo/), of een sjabloonrepository die je provider je geeft.
Pas het aan met de mapping. Verwijder inhoud die niet van toepassing is (spokes van andere klanten, voorbeeldpolicies die je niet wilt).
Stel in elke entry pipeline (pipelines/*.yaml of .github/workflows/*.yaml) de verwijzing naar de coderepository en de gepinde versie in (Versiebeheer), evenals de agent pool, de service connections en de omgevingen.
Commit en push naar initial.

Blijf op initial werken totdat het platform is gevalideerd. Zo beschrijft main altijd een configuratie die is uitgerold en gecontroleerd, en vertragen de branchbeveiligingen hieronder de implementatie niet.

4. Beveilig de repositories aan het eind van de implementatie¶

Schakel dit in na de validatie, vóór de overdracht. Gebruik een groep reviewers waarmee de klant akkoord is (voorbeeldnaam: <platform approvers group>).

Beveiliging	Azure DevOps	GitHub
Goedkeuring vóór prod-runs	Environment `prod` (en een spoke-omgeving zoals `<spoke environment>-prod`) met approvers; projectbeheerders hebben de rol Administrator erop; approvers mogen hun eigen runs niet goedkeuren	Environment `prod` met required reviewers (de approvergroep), Prevent self-review aan, Allow administrators to bypass uit. Ook de environment `approval-required` voor de `Approve*`-modi (Pipelines).
Review vóór merge naar `main`	Een cross-repository branch policy op de standaardbranch: automatisch toegevoegde reviewers = de approvergroep, verplicht, minimaal 1 reviewer, aanvragers mogen hun eigen wijzigingen niet goedkeuren	Een ruleset op `main`: pull request met 1 goedkeuring verplicht, goedkeuring van de meest recente reviewbare push, afhandeling van conversaties, alleen squash merge, force pushes geblokkeerd
Spoke-bestanden geverifieerd vóór merge	Build validation op de configuratierepository: de spoke-verificatiepipeline, automatische trigger, verplicht, build expiration 12 uur	Een pull request-workflow die de config tests draait
Leestoegang voor approvers	De approvergroep kan de repositories lezen	De approvergroep heeft leestoegang tot de repositories

Open ten slotte een pull request van initial naar main en merge die. Zet in GitHub de standaardbranch terug op main en werk de federated credential voor de branch bij (zie GitHub-variant).

Oudere indelingen¶

Oudere indeling	Vervangen door	Opmerkingen
Vier repositories: platformcode, platformconfig, spoke canvas-code, spoke canvas-config	Twee repositories (code en configuratie) in de huidige indeling	In de oudere indeling staan de spoke-bestanden in `spokes/tfspokes/<workload>/` van de spoke-configuratierepository, en de spoke-deployment gebruikt een eigen pipeline en state-container.
Een aparte repository voor de self-hosted agents (Terraform en een image build)	De `infrastructure`- en `container`-pipelines in de coderepository	Zie Pipelines en agents.
Eén repository per klant met alle code en parameters (monorepo), of één `landingzone.yml`-pipeline	Gelaagde deployment	Zie Migreren vanaf een oudere platformversie.

Controleer welke indeling je gepinde versie verwacht: de entry pipelines en de release notes van de versie vertellen het je.

Voor de spoke canvas als aparte deployment (eigen coderepository en pipeline), zie De spoke pipeline voorbereiden: de code blijft ofwel bij het platformteam en wordt gelezen via een service connection, ofwel wordt gekopieerd naar de organisatie van de klant.