Zum Inhalt

Repo-Setup

Die Plattform ist auf zwei Arten von Git-Repositories verteilt: Code und Config.

flowchart LR
    code["Code<br/>xms-cloud-platform-code<br/>eines für alle Kunden"]
    config["Config<br/>eines pro Kunde<br/>z. B. xms-cloud-platform-config"]
    config -- "pins release/vX.Y<br/>(Entry-pipelines)" --> code
    code -. "Layers lesen<br/>Werte aus" .-> config
Code-Repository Konfigurations-Repository
Name xms-cloud-platform-code Eines pro Kunde, zum Beispiel xms-cloud-platform-config (XDEV)
Gehostet GitHub Enterprise xebia-managed-services-eu.ghe.com/xmms, synchronisiert auf Kunden-Remotes Im Azure DevOps oder GitHub des Kunden
Enthält Terraform-layers und -modules, das PowerShell-Modul Xebia.Mcp, JSON-Schemas, pipeline-Templates, das mcp-Dockerfile, die Demo-Konfiguration mcp.json, *.auto.tfvars, JSON-Dateien für Firewall, IP groups, App Gateway, WAF, Policies und spokes sowie die Entry-pipelines
Geändert von Plattform-Entwicklern Plattform-Operatoren. Alle Standardänderungen passieren hier.
Versioniert als Release-Branches release/vX.Y, tags vX.Y.Z main beschreibt, was deployt ist
Mehr lesen Code Config

Das Konfigurations-Repository enthält kein Terraform. Seine Entry-pipelines checken das Code-Repository in einer fixierten Version aus und übergeben den Pfad zu einer mcp.json.

Spoke-Dateien gehören zum Konfigurations-Repository (<env-folder>/spokes/), und das Terraform des spoke canvas gehört zum Code-Repository. Ältere Versionen nutzten vier Repositories, siehe Ältere Layouts.

Wie der Code zu den Kunden kommt

  1. Änderungen werden in main des Code-Repositorys auf GitHub Enterprise gemergt.
  2. Ein release-Branch release/vX.Y wird abgezweigt, und darauf werden die tags vX.Y.Z erstellt.
  3. Der Workflow trigger-sync.yaml läuft bei jedem Push auf main, release/** und v*-tags. Er ruft den Dispatcher xmms/xms-code-sync auf, der das Code-Repository auf die Kunden-Remotes synchronisiert.
  4. Das Konfigurations-Repository des Kunden fixiert die Version in seinen Entry-pipelines. Siehe Versionierung.

Die Repositories für einen neuen Kunden einrichten

Lege beide Repositories im Azure-DevOps-Projekt oder in der GitHub-Organisation des Kunden an, bringe den veröffentlichten Code ein und befülle das Konfigurations-Repository aus dem Template. Die Schritte, das sync-Ziel auf GitHub und die Schutzmaßnahmen, die du am Ende aktivierst, stehen unter Repositories vorbereiten.

Zwei Regeln gelten in jedem Setup:

  • Niemand bearbeitet das Code-Repository auf dem Host des Kunden. Es erhält nur veröffentlichte Branches und tags. Mache es für alle außer dem sync schreibgeschützt.
  • Alle Standardänderungen passieren im Konfigurations-Repository, per pull request. Schütze den Default-Branch mit einem verpflichtenden Review (eine zweite Person) und schütze Produktionsläufe mit einem approval environment.

Arbeite, solange die Plattform implementiert wird, auf einem separaten Branch initial des Konfigurations-Repositorys und merge ihn nach main, wenn die Validierung bestanden ist. So beschreibt main immer eine Konfiguration, die deployt und geprüft wurde.

Ältere Layouts

Ältere Versionen der Plattform nutzten vier Repositories: Plattform-Code und Plattform-Config sowie je ein Repository für Code und Config des spoke canvas. In diesem Layout lagen die Spoke-Dateien in spokes/tfspokes/<workload>/ des Spoke-Config- Repositorys, und die selbst gehosteten Agents hatten ein eigenes Repository. Das aktuelle Layout hat die beiden oben genannten Repositories. Siehe Von einer älteren Plattformversion migrieren.

Weitere Repositories

Repository Rolle
XMS (Azure DevOps) Bisherige Plattform-Dokumentation, Kundenseiten und Runbooks. Wird durch diese Site ersetzt.
xms-code-sync Dispatcher, der das Code-Repository auf Kunden-Remotes synchronisiert.
pdk-docs Diese Dokumentations-Site (MkDocs Material).

Der Pfeil zwischen Code und Config

Ein layer im Code-Repository liest nur Dateien aus dem Konfigurations-Repository. Wenn du ein neues Feature baust, brauchst du meist auch neue Konfiguration: eine neue Variable in einer *.auto.tfvars-Datei oder eine neue JSON-Property. Deshalb verlinken die Code- und Config-Bereiche dieser Site aufeinander: