Releases en upgradebegeleiding¶
Klanten pinnen een versie van de coderepository en upgraden wanneer ze willen, soms over meerdere versies tegelijk. Dit onderdeel helpt het platformteam te zien wat er tussen versies is veranderd en wat het met de hand moet doen als het een nieuwe versie neemt.
Wie het platformteam is, hangt af van je beheermodel: XMMS-engineers in het managed model, je eigen engineers in het zelfbeheermodel.
Pagina's in dit onderdeel¶
| Pagina | Gebruik haar om |
|---|---|
| Releasegeschiedenis | te zien wat elke major- en minorversie bracht, en welke versies handmatige stappen nodig hadden |
| Upgradehandleidingen voor het platform | de versiespecifieke stappen uit te voeren van v4.4.0 tot en met v4.12.x |
| Upgradehandleidingen voor spoke canvas | de versiespecifieke stappen uit te voeren voor het oudere, afzonderlijke spoke canvas (v2.9.x en v2.10.0), en te zien wat elke instelling van de common.tf doet |
| Generiek updaterunbook | de updateflow van de oudere repositories met één pipeline te volgen |
| Wat te doen als een nieuwe versie wordt gereleased | de huidige upgradeprocedure te volgen (hub-, spoke- en tooling-pipelines) |
Voor wie releases maakt, zie Releasen; de opmaak en toon van release notes staan in de Release note conventions. Voor de regels die upgrades veilig houden, zie Achterwaartse compatibiliteit.
Hoe versies werken¶
| Versieverhoging | Wat je kunt verwachten |
|---|---|
Patch (v4.12.1 naar v4.12.2) |
Alleen bugfixes. Geen configuratiewijzigingen. |
Minor (v4.11.x naar v4.12.0) |
Nieuwe functies, opt-in. Een versiespecifieke upgradehandleiding noemt eventuele handmatige stappen. |
Major (v4.x naar v5.0) |
Breaking changes zijn mogelijk. Bij elk ervan hoort een migratie in de upgradehandleiding. |
Een configuratierepository van een klant pint een releasebranch (bijvoorbeeld release/v4.12) of een tag. Een releasebranch levert
je elke patch automatisch bij de volgende run. Zie
Versiebeheer.
Het contract is niet altijd nagekomen
Sommige minorversies in de geschiedenis hadden handmatige stappen nodig, zoals het verwijderen van policy assignments in de Azure portal of het bewerken van bestanden in de configuratierepository. Die stappen zijn de reden dat er upgradehandleidingen bestaan. Lees altijd de handleiding van elke versie tussen je huidige versie en je doelversie.
Hoe je een release note leest¶
Release notes gebruiken in elke versie dezelfde paar koppen, zodat je ze snel kunt scannen:
| Kop | Wat het je vertelt | Moet je iets doen? |
|---|---|---|
| New features | Iets wat je kunt aanzetten. Opt-in | Alleen als je het wilt |
| Improvements | Bestaand gedrag dat beter is geworden | Nee |
| Bug fixes | Iets wat niet werkte en nu wel | Misschien: controleer of je een workaround hebt gebouwd |
| Breaking changes | Een wijziging waarvoor jij een stap moet zetten | Ja. Zoek naar de upgradehandleiding |
| Known issues | Een probleem dat nog niet is opgelost | Lees het voordat je upgradet |
Een titel als ... version 2.6.0 - Minor Release noemt de bump. Een patchrelease vraagt geen configuratiewijziging. Een
minorrelease kan een upgradehandleiding hebben. Bij een majorrelease mag je er een verwachten.
Waar vind je wat¶
| Vraag | Antwoord |
|---|---|
| Welke versie draai ik? | De pin in elke entry pipeline van de configuratierepository (stap 1) |
| Wat is er in een versie veranderd? | De release notes in de geschiedenis en de release notes van de coderepository |
| Moet ik iets met de hand doen? | De upgradehandleidingen voor het platform. Een versie zonder handleiding heeft geen speciale stappen nodig |
| In welke volgorde draai ik de layers? | Deployment layers. Verouderde volgorde: Generiek updaterunbook |
| Hoe weet ik dat de upgrade is gelukt? | Een hub-run vanaf main plant geen wijzigingen (stap 8) |
Dekking van de release notes¶
De release notes in deze documentatie zijn samengevat uit de notes die per versie worden bijgehouden:
- v2.0 tot en met v4.6.1 hebben release notes. v3.3 tot en met v4.3 hebben er geen.
- Vanaf v4.7 zijn er upgradehandleidingen (v4.7.0, v4.9.0, v4.11.x, v4.12.x) maar geen aparte release notes. De geschiedenis noemt wat die handleidingen laten zien.
- De nieuwste tags op het moment van schrijven staan op
release/v4.12. Kijk in de coderepository voor de laatste patch (Releasestatus nu).