Zum Inhalt

Was zu tun ist, wenn eine neue Version veröffentlicht wird

Diese Seite richtet sich an Engineers, die das Konfigurations-Repository eines Kunden auf eine neuere Version des Code- Repositorys upgraden. Wie du einen release erstellst, steht unter Releasing. Was sich in jeder Version geändert hat, steht in der Release-Historie, und eine Übersicht des Bereichs gibt Releases und Upgrade-Hinweise.

Wer das Upgrade durchführt, hängt vom Betriebsmodell ab: XMMS-Engineers im managed Modell, das Plattform-Team des Kunden im Eigenbetrieb.

Versionierung: wie das Konfigurations-Repository den Code fixiert

Du wählst die Code-Version in jeder Entry-pipeline des Konfigurations-Repositorys.

Azure DevOps: die Repository-Ressource mcp-code und ihr ref:

variables:
  - template: variables.yaml
  - name: mcpRef
    value: release/v4.12

resources:
  repositories:
    - repository: mcp-code
      endpoint: xebia-managed-services-eu.ghe.com
      type: githubenterprise
      name: xmms/xms-cloud-platform-code
      ref: $(mcpRef)

GitHub Actions: die uses:-Referenz und der Input mcpCodeRef (halte beide identisch):

jobs:
  canary:
    uses: xmms/xms-cloud-platform-code/.github/workflows/stage-mcp-hub.yaml@release/v4.12
    with:
      mcpCodeRef: release/v4.12

Wenn du release/vX.Y fixierst, erhältst du automatisch jeden patch auf diesem Branch. Fixiere einen tag (v4.12.2), wenn der Kunde eine feste Version braucht.

Legacy-pipelines

Um einen Tenant von den Legacy-pipelines auf die Entry-pipelines umzustellen, siehe Migration von einer älteren Plattformversion.

Ältere Kunden-Repositories verwenden eine einzelne pipelines/main.yaml (Azure DevOps) oder .github/workflows/main.yaml mit environment_canary.yml@v… / environment_prod.yml@v… und führen jeweils einen layer nach dem anderen aus. Die folgenden Schritte gelten weiterhin; aktualisiere jede ref:- und @v…-Referenz in diesen Dateien und führe die layers einzeln in der Reihenfolge foundation, connectivity, (ghrunners), identity, management, firewall, postdeployment aus. Den Ablauf mit einer einzelnen pipeline beschreibt das Generische Update-Runbook.

Upgrade-Schritte

flowchart LR
    a["1. Aktuelle Version"] --> b["2. Upgrade-Leitfäden"] --> c["3. Branch + Vorarbeiten"] --> d["4. pin anheben"]
    d --> e["5. infrastructure + container"] --> f["6. Canary: plan → apply"] --> g["7. Prod"] --> h["8. Mergen + festhalten"]

1. Die aktuelle Version prüfen

Öffne die Entry-pipelines im Konfigurations-Repository und notiere den aktuellen mcpRef / ref / @…. Alle Entry- Dateien müssen denselben Wert haben; wenn sie abweichen, finde den Grund heraus, bevor du weitermachst.

2. Die Upgrade-Leitfäden lesen

Lies den versionsspezifischen Upgrade-Leitfaden jeder Version zwischen der aktuellen und der Zielversion, die älteste zuerst. Die Leitfäden sind kumulativ. Wenn eine Version keinen Leitfaden hat, braucht sie keine besonderen Schritte.

Die Leitfäden für v4.4.0 bis v4.12.x stehen unter Plattform-Upgrade-Leitfäden. Die Leitfäden des älteren, separaten spoke canvas stehen unter Upgrade-Leitfäden für das Spoke canvas. Was jede Version gebracht hat, liest du in der Release-Historie.

Aktuelle Beispiele:

Upgrade Was der Leitfaden verlangt
auf v4.11.x (von v4.9.x) Die alten DNS-Policy-Definitionen und -initiatives sowie die BIO-initiative aus dem Konfigurations-Repository löschen; die alte DNS-Policy-Assignment-Datei löschen; die Assignments und initiatives Alerting-LandingZone und XMS-Deploy-DNS-Zones im portal entfernen
auf v4.12.x (von v4.11.x) Das Assignment und die initiative XMMS-Private-DNS-Zones im portal entfernen; sicherstellen, dass jede App-Gateway-JSON eine gültige firewall_policy_id hat (klein geschriebenes applicationGatewayWebApplicationFirewallPolicies)

3. Einen Branch erstellen und die Vorarbeiten erledigen

git checkout -b users/<initials>/update-to-v<version>

Erledige die Schritte der Leitfäden, die das Konfigurations-Repository betreffen, auf diesem Branch. Beantrage PIM-Elevation, wenn ein Leitfaden portal- Änderungen verlangt, und räume im portal auf, bevor du weitermachst.

4. Den pin anheben

Ändere jeden mcpRef / ref / uses: …@ / mcpCodeRef in allen Entry-pipelines (hub, hub-destroy, spoke, spoke-destroy, infrastructure, container) in einem Commit.

5. Das Tooling neu bauen

  1. Wenn der release das job-runner-Bicep ändert (src/Xebia.Mcp/Files/bicep/), führe zuerst infrastructure aus.
  2. Führe container aus, damit das mcp-Image aus der neuen Code-Version neu gebaut wird.

6. Canary: planen, prüfen, anwenden

Kündige das Zeitfenster zuerst den Workload-Teams an (Wartungskalender).

Führe hub von deinem Branch im Plan-mode (oder ApproveModifications) aus und lies den Plan jedes layers:

  • Erwartet: die in den Upgrade-Leitfäden und release notes aufgeführten Änderungen.
  • Stopp bei unerwarteten Destroys oder Replacements. Im Zweifel frage das XMMS-Produktteam, bevor du anwendest. Im managed Modell führen XMMS-Engineers diese Prüfung durch. Im Eigenbetrieb macht das das Plattform-Team des Kunden und fragt dann XMMS, wenn es unsicher ist.

Wende auf canary an. Führe danach spoke im Plan mode für einen spoke pro spoke-Umgebung aus und prüfe, dass die spokes keine unerwarteten Änderungen zeigen.

Die spoke-Pläne lesen

Nach einem Upgrade zeigen sich Überraschungen in den spoke-Plänen. Führe spoke im Plan-mode für jeden spoke aus (oder mindestens für einen pro Art von spoke) und halte das Ergebnis pro spoke fest: keine Änderungen, erwartete Änderungen oder muss angesehen werden. Pläne auf einer laufenden Plattform zeigen nach einem Upgrade typischerweise diese erwarteten Änderungen:

Änderung im Plan Bedeutet meist
Das Passwort eines spoke-Service-Principals „will be rotated“ Der Rotationszeitraum ist abgelaufen. Das nächste Apply rotiert es. Wenn ein Team bereits von Hand ein neues Secret erstellt hat, sag ihm Bescheid. Federated credentials werden nicht rotiert (Spoke ändern)
Der Netzwerkzugriff eines Key Vaults aus einem Subnet „will be removed“, oder ein Service Endpoint „will be removed“ von einem Subnet Der Code erstellt diesen Zugriff nicht mehr, also wurde etwas von Hand oder von einer älteren Version hinzugefügt. Frag das Workload-Team, ob er noch gebraucht wird. Wenn ja, füge ihn in der spoke-Konfiguration hinzu, bevor du anwendest
Eine NSG-Zuordnung „will be created“ auf einem Subnet Ein Subnet ohne NSG bekommt die Baseline-NSG. Prüfe, dass die NSG-Regeln keinen Verkehr abschneiden, der heute funktioniert
Eine NSG-Regel „will be removed“ Die Regel stand nicht im Code. Kläre es mit dem Workload-Team
Log Analytics daily_quota_gb oder retention_in_days ändert sich Die spoke-Konfiguration weicht vom Workspace ab. Entscheide, welcher Wert richtig ist, bevor du anwendest
Alles, was die Zuordnung einer subscription, einen Key Vault, ein storage account oder ein virtuelles Netzwerk zerstört Stopp. Behandle es als unerwartet (Bekannte Probleme)

Halte die Liste der spokes und das Ergebnis pro spoke in einer Tabelle im Work Item fest und führe die fehlgeschlagenen erneut aus, nachdem du sie behoben hast. Wende keinen spoke-Plan an, den du nicht gelesen hast.

7. Prod

Wiederhole Schritt 6 für prod. Nimm prod-spezifische Änderungen nur vor, wo der Leitfaden es vorsieht.

8. Mergen und festhalten

  1. Merge den Branch nach main.
  2. Führe hub noch einmal von main aus und prüfe, dass er keine Änderungen plant.
  3. Halte die neue Version im Work Item fest, und in der Kundenübersicht, falls du eine pflegst. (Die pipeline report-version meldet fixierte Versionen automatisch an die Status-API.)

Checkliste

  • [ ] Aktuelle Version festgehalten
  • [ ] Alle Upgrade-Leitfäden zwischen aktueller und Zielversion gelesen und umgesetzt
  • [ ] Jede Entry-pipeline fixiert dieselbe Zielversion
  • [ ] infrastructure (falls nötig) und container ausgeführt
  • [ ] Canary-hub geplant, geprüft, angewendet
  • [ ] Spokes geplant, jeder Plan gelesen, und unerwartete Änderungen erklärt oder behoben
  • [ ] Prod-hub geplant, geprüft, angewendet
  • [ ] Gemergt; ein Lauf von main plant keine Änderungen