Releases und Upgrade-Hinweise¶
Kunden fixieren eine Version des Code-Repositorys und upgraden, wann sie wollen, manchmal über mehrere Versionen auf einmal. Dieser Abschnitt hilft dem Plattform-Team zu sehen, was sich zwischen Versionen geändert hat und was es von Hand tun muss, wenn es eine neue Version übernimmt.
Wer das Plattform-Team ist, hängt von deinem Betriebsmodell ab: XMMS-Engineers im Managed-Service-Modell, deine eigenen Engineers im Eigenbetrieb.
Seiten in diesem Abschnitt¶
| Seite | Nutze sie, um |
|---|---|
| Release-Historie | zu sehen, was jede Major- und Minor-Version gebracht hat und welche Versionen manuelle Schritte brauchten |
| Upgrade-Leitfäden der Plattform | die versionsspezifischen Schritte von v4.4.0 bis v4.12.x auszuführen |
| Upgrade-Leitfäden für den spoke canvas | die versionsspezifischen Schritte für den älteren, separaten spoke canvas (v2.9.x und v2.10.0) auszuführen und zu sehen, was jede Einstellung seiner common.tf bewirkt |
| Allgemeines Update-Runbook | dem Update-Ablauf der älteren Repositories mit einer einzigen pipeline zu folgen |
| Was zu tun ist, wenn eine neue Version veröffentlicht wird | dem aktuellen Upgrade-Verfahren zu folgen (hub, spoke und Tooling-pipelines) |
Für die Menschen, die Releases erstellen, siehe Releasing; Format und Ton der release notes stehen unter Konventionen für release notes. Für die Regeln, die Upgrades sicher halten, siehe Abwärtskompatibilität.
So funktionieren Versionen¶
| Versionssprung | Was du erwarten kannst |
|---|---|
Patch (v4.12.1 auf v4.12.2) |
Nur Bugfixes. Keine Konfigurationsänderungen. |
Minor (v4.11.x auf v4.12.0) |
Neue Features, opt-in. Ein versionsspezifischer Upgrade-Leitfaden listet jeden manuellen Schritt auf. |
Major (v4.x auf v5.0) |
Breaking Changes sind möglich. Jede kommt mit einer Migration im Upgrade-Leitfaden. |
Das Konfigurations-Repository eines Kunden fixiert einen Release-Branch (zum Beispiel release/v4.12) oder einen tag. Ein Release-Branch liefert
dir jeden Patch automatisch beim nächsten Lauf. Siehe
Versionierung.
Der Vertrag wurde nicht immer eingehalten
Einige Minor-Versionen in der Historie brauchten manuelle Schritte, etwa das Entfernen von policy assignments im Azure-Portal oder das Bearbeiten von Dateien im Konfigurations-Repository. Diese Schritte sind der Grund, warum es Upgrade-Leitfäden gibt. Lies immer den Leitfaden jeder Version zwischen deiner aktuellen und deiner Zielversion.
So liest du eine Release Note¶
Release notes verwenden in jeder Version dieselben wenigen Überschriften, sodass du sie schnell überfliegen kannst:
| Überschrift | Was sie dir sagt | Musst du handeln? |
|---|---|---|
| New features | Etwas, das du einschalten kannst. Opt-in | Nur, wenn du es willst |
| Improvements | Bestehendes Verhalten, das besser geworden ist | Nein |
| Bug fixes | Etwas, das nicht funktioniert hat und jetzt funktioniert | Vielleicht: prüfe, ob du einen Workaround gebaut hast |
| Breaking changes | Eine Änderung, die einen Schritt von dir braucht | Ja. Suche den Upgrade-Leitfaden |
| Known issues | Ein Problem, das noch nicht behoben ist | Lies es, bevor du upgradest |
Ein Titel wie ... version 2.6.0 - Minor Release nennt den Versionssprung. Ein Patch-Release braucht keine Konfigurationsänderung.
Ein Minor-Release kann einen Upgrade-Leitfaden haben. Bei einem Major-Release erwarte einen.
Wo du was findest¶
| Frage | Antwort |
|---|---|
| Welche Version betreibe ich? | Der pin in jeder Entry-pipeline des Konfigurations-Repositorys (Schritt 1) |
| Was hat sich in einer Version geändert? | Die release notes in der Historie und die release notes des Code-Repositorys |
| Muss ich etwas von Hand tun? | Die Upgrade-Leitfäden der Plattform. Eine Version ohne Leitfaden braucht keine besonderen Schritte |
| In welcher Reihenfolge führe ich die layers aus? | Deployment-Layer. Frühere Reihenfolge: Allgemeines Update-Runbook |
| Woran erkenne ich, dass das Upgrade funktioniert hat? | Ein hub-Lauf von main plant keine Änderungen (Schritt 8) |
Abdeckung der release notes¶
Die release notes in dieser Dokumentation sind aus den Notizen verdichtet, die für jede Version geführt werden:
- v2.0 bis v4.6.1 haben release notes. v3.3 bis v4.3 haben keine.
- Ab v4.7 gibt es Upgrade-Leitfäden (v4.7.0, v4.9.0, v4.11.x, v4.12.x), aber keine separaten release notes. Die Historie listet auf, was diese Leitfäden zeigen.
- Die neuesten tags stehen zum Zeitpunkt des Schreibens auf
release/v4.12. Prüfe im Code-Repository den neuesten Patch (Release-Stand heute).