Ga naar inhoud

Wat te doen als een nieuwe versie wordt gereleased

Deze pagina is voor de engineer die de configuratierepository van een klant upgradet naar een nieuwere versie van de code repository. Om een release te maken, zie Releasen. Voor wat er in elke versie is veranderd, zie de Releasegeschiedenis, en voor het overzicht van de sectie Releases en upgradebegeleiding.

Wie de upgrade doet, hangt af van het beheermodel: XMMS-engineers in het managed model, het platformteam van de klant in het zelfbeheermodel.

Versionering: hoe de configuratierepository de code vastpint

Je kiest de codeversie in elke entry pipeline van de configuratierepository.

Azure DevOps: de repository resource mcp-code en de bijbehorende 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: de uses:-verwijzing en de mcpCodeRef input (houd ze identiek):

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

Door release/vX.Y te pinnen krijg je automatisch elke patch op die branch. Pin een tag (v4.12.2) als de klant een vaste versie nodig heeft.

Legacy pipelines

Om een tenant van de legacy pipelines naar de entry pipelines te verplaatsen, zie Migreren vanaf een oudere platformversie.

Oudere klantrepositories gebruiken één pipelines/main.yaml (Azure DevOps) of .github/workflows/main.yaml met environment_canary.yml@v… / environment_prod.yml@v…, en draaien één layer tegelijk. De onderstaande stappen gelden nog steeds; werk elke ref:- en @v…-verwijzing in die bestanden bij, en draai de layers een voor een in de volgorde foundation, connectivity, (ghrunners), identity, management, firewall, postdeployment. De flow met één pipeline staat uitgeschreven in het Generieke updaterunbook.

Upgradestappen

flowchart LR
    a["1. Huidige versie"] --> b["2. Upgradehandleidingen"] --> c["3. Branch + voorbereidende stappen"] --> d["4. Pin ophogen"]
    d --> e["5. infrastructure + container"] --> f["6. Canary: plan → apply"] --> g["7. Prod"] --> h["8. Mergen + vastleggen"]

1. Controleer de huidige versie

Open de entry pipelines in de configuratierepository en noteer de huidige mcpRef / ref / @…. Alle entry- bestanden moeten dezelfde waarde hebben; als ze verschillen, zoek dan uit waarom voordat je verdergaat.

2. Lees de upgradehandleidingen

Lees de versiespecifieke upgradehandleiding van elke versie tussen de huidige en de doelversie, oudste eerst. De handleidingen zijn cumulatief. Als een versie geen handleiding heeft, zijn er geen bijzondere stappen nodig.

De handleidingen voor v4.4.0 tot en met v4.12.x staan in Platform upgrade guides. De handleidingen van het oudere, aparte spoke canvas staan in Spoke canvas upgrade guides. Wil je zien wat elke versie bracht, lees dan de Releasegeschiedenis.

Recente voorbeelden:

Upgrade Wat de handleiding vraagt
naar v4.11.x (vanaf v4.9.x) Verwijder de oude DNS policy definitions en initiatives en het BIO initiative uit de configuratierepository; verwijder het oude DNS policy assignment-bestand; verwijder de Alerting-LandingZone en XMS-Deploy-DNS-Zones assignments en initiatives in de portal
naar v4.12.x (vanaf v4.11.x) Verwijder de XMMS-Private-DNS-Zones assignment en initiative in de portal; zorg dat elke App Gateway JSON een geldige firewall_policy_id heeft (kleine letters applicationGatewayWebApplicationFirewallPolicies)

3. Maak een branch en doe de voorbereidende stappen

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

Voer de stappen voor de configuratierepository uit de handleidingen uit op deze branch. Vraag PIM-elevatie aan als een handleiding portalwijzigingen vereist, en doe de opschoning in de portal voordat je verdergaat.

4. Verhoog de pin

Wijzig elke mcpRef / ref / uses: …@ / mcpCodeRef in alle entry pipelines (hub, hub-destroy, spoke, spoke-destroy, infrastructure, container) in één commit.

5. Bouw de tooling opnieuw

  1. Als de release de Bicep van de job runners wijzigt (src/Xebia.Mcp/Files/bicep/), draai dan eerst infrastructure.
  2. Draai container, zodat de mcp image opnieuw wordt gebouwd vanuit de nieuwe codeversie.

6. Canary: plan, review, apply

Kondig het venster eerst aan bij de workload teams (Onderhoudskalender).

Draai hub vanaf je branch in Plan-modus (of ApproveModifications) en lees de plan van elke layer:

  • Verwacht: de wijzigingen die in de upgradehandleidingen en release notes staan.
  • Stop bij onverwachte destroys of replacements. Vraag bij twijfel het XMMS-productteam voordat je apply uitvoert. In het managed model doen XMMS-engineers deze controle. In het zelfbeheermodel doet het platformteam van de klant dit, en vraagt daarna XMMS als het onzeker is.

Pas toe op canary. Draai daarna spoke in Plan-modus voor één spoke per spoke-omgeving en controleer dat de spokes geen onverwachte wijzigingen tonen.

De spoke-plans lezen

Na een upgrade komen de verrassingen naar boven in de spoke-plans. Draai spoke in Plan-modus voor elke spoke (of minstens één per soort spoke) en noteer het resultaat per spoke: geen wijzigingen, verwachte wijzigingen of moet bekeken worden. Plans op een draaiend platform tonen na een upgrade meestal deze verwachte wijzigingen:

Wijziging in de plan Betekent meestal
Het wachtwoord van een spoke service principal "will be rotated" De rotatieperiode is verstreken. De volgende apply roteert het. Heeft een team al met de hand een nieuw secret aangemaakt, meld dat dan. Federated credentials worden niet geroteerd (Spoke wijzigen)
Netwerktoegang van een Key Vault vanaf een subnet "will be removed", of een service endpoint "will be removed" van een subnet De code maakt die toegang niet meer aan, dus iets is met de hand of door een oudere versie toegevoegd. Vraag het workload team of het nog nodig is. Zo ja, voeg het toe in de spoke-configuratie voordat je apply uitvoert
Een NSG-koppeling "will be created" op een subnet Een subnet zonder NSG krijgt de baseline-NSG. Controleer dat de NSG-regels geen verkeer afsnijden dat nu werkt
Een NSG-regel "will be removed" De regel stond niet in de code. Bevestig met het workload team
Log Analytics daily_quota_gb of retention_in_days verandert De spoke-configuratie wijkt af van de workspace. Bepaal welke waarde klopt voordat je apply uitvoert
Alles wat de koppeling van een subscription, een Key Vault, een storage account of een virtual network vernietigt Stop. Behandel als onverwacht (Bekende problemen)

Houd de lijst met spokes en het resultaat per spoke bij in een tabel in het work item, en draai de mislukte opnieuw nadat je ze hebt opgelost. Pas geen spoke-plan toe die je niet hebt gelezen.

7. Prod

Herhaal stap 6 voor prod. Maak alleen prod-specifieke wijzigingen waar de handleiding dat aangeeft.

8. Mergen en vastleggen

  1. Merge de branch naar main.
  2. Draai hub nog een keer vanaf main en controleer dat de plan geen wijzigingen toont.
  3. Leg de nieuwe versie vast op het work item, en in het klantoverzicht als je er een bijhoudt. (De report-version pipeline rapporteert vastgepinde versies automatisch aan de status-API.)

Checklist

  • [ ] Huidige versie vastgelegd
  • [ ] Alle upgradehandleidingen tussen huidige en doelversie gelezen en uitgevoerd
  • [ ] Elke entry pipeline pint dezelfde doelversie
  • [ ] infrastructure (indien nodig) en container gedraaid
  • [ ] Canary hub gepland, gereviewd, toegepast
  • [ ] Spokes gepland, elke plan gelezen en onverwachte wijzigingen verklaard of opgelost
  • [ ] Prod hub gepland, gereviewd, toegepast
  • [ ] Gemerged; een run vanaf main plant geen wijzigingen