MO-82 [SR] Aanpassing Release cycle management en versienummer beheer
Samenvatting
Waarom is deze RFC nodig? | |
---|---|
Oplossingsrichting | Release-cycle-management omvat nu Major, Minor en Patch releases waarbij 2 x per jaar een major release slot wordt vastgesteld. Minors gaan in de basis mee met de Major release slots. Patches hebben 12 release slots per jaar (maandelijks). Om de releases en wijzigingen te identificeren (NEN-7522 eis) wordt de versienummering gebaseerd op SemVer (best practice). Waarbij de aankomende release candidate (MMOptioneel) het nummer 2.0.0 krijgt. |
RACI |
|
Aanpassing van | MMverplicht 1.6.0 en MMOptioneel 2.0.0 |
Impact op rollen | n.v.t |
Impact op beheer | Versienummer reflecteert impact op compatibiliteit (SemVer, major is niet backward compatible). |
Impact op R&A | Voor de R&A zal voor versie 2.0.0 alleen het Major nummer als API nummer worden opgevoerd. Dit betekent dat er voor het doorvoeren van minor en patch-releases (dit zijn per definitie compatible wijzigingen) geen R&A aanpassing nodig is. |
Impact op Acceptatie | Acceptatie team zal eerder betrokken worden bij impact analyses van de voorgestelde wijzigingen (en bijbehorende tijdslijn t.a.v. implementatie voor acceptatie). |
PIA noodzakelijk | Nee |
Gerelateerd aan (Andere RFCs, PIM issues) | MO-17 en MO-30 vormen de basis (MO-06 is de initiele behoefte [USM Afspreken] |
Implementatietermijn | release 2023-19 |
Motivatie verkorte RFC procedure (patch) |
Uitwerking
aanpassingen doorvoeren op:
- MMVerplicht 1.6.0
- MMOptioneel 2.0.0
Locatie | Oorspronkelijke tekst | Aangepaste tekst |
---|---|---|
Change- en releasebeleid | ||
Releasecyclus | De wijzigingen aan het stelsel vinden zoveel mogelijk plaats aan de hand van een vaste releasecyclus en een releaseplanning met release momenten in april en oktober. Stichting MedMij speelt hierbij een aanjagende en faciliterende rol met een aantal verantwoordelijkheden, namelijk: het samenstellen van samenhangende releases, het ophalen van input bij belanghebbenden, het uitvoeren van impactanalyses, het organiseren van de besluitvorming en de informatievoorziening eromheen en het bewaken van ontwikkelingen in de omgeving (bijvoorbeeld veranderende wetgeving). Ook is zij voortdurend attent op wijzigingen in gebruikte normen en standaarden en heroverweegt in voorkomend geval het hergebruik. Jaarlijks stelt Stichting MedMij samen met de verschillende belanghebbenden een releaseplanning op. De releaseplanning bevat een overzicht van geplande releases voor de periode van een jaar, geeft aan wat de belangrijkste voorgenomen wijzigingen zijn per release en duidt per geplande release de mijlpalen van het ontwikkel- en implementatietraject aan. Wijzigingen betreffende de inhoud van het afsprakenstelsel moeten passen binnen deze releaseplanning. De releaseplanning moet op haar beurt weer passen binnen de strategische kaders. Het bestuur van Stichting MedMij stelt de releaseplanning vast. | De wijzigingen aan het stelsel vinden zoveel mogelijk plaats
Ook is Jaarlijks stelt Stichting MedMij samen met de verschillende belanghebbenden een release roadmap op. De roadmap bevat een overzicht van geplande releases voor de periode van een jaar en geeft aan wat de belangrijkste voorgenomen wijzigingen zijn per release. Wijzigingen |
Dakpansgewijze releases | Dat wil zeggen dat alle Deelnemers op zijn minst deze verplichte versie moeten ondersteunen. De andere actieve release heet gepubliceerd. | Dat wil zeggen dat alle Deelnemers |
Wanneer een nieuwe release uitkomt van het MedMij Afsprakenstelsel, krijgt:
Steeds schuift dus de nieuwste release (de gepubliceerde) als een nieuwe dakpan half bovenop de (dan) verplichte. Alleen de bovenste twee dakpannen zijn actief. Hun overlap symboliseert het tegelijkertijd actief zijn op het MedMij-netwerk. Omdat MedMij een vast release-ritme hanteert (van eens per half jaar), is die overlap een halve dakpan groot. Onder de verplichte release liggen de verouderde releases, als inactieve geschiedenis van het MedMij Afsprakenstelsel. | Wanneer een nieuwe release uitkomt van het MedMij Afsprakenstelsel, krijgt:
Steeds schuift de nieuwste release (de release candidate) als een nieuwe dakpan half bovenop de (dan) verplichte versie. Alleen de bovenste twee dakpannen zijn actief. Hun overlap symboliseert het tegelijkertijd actief zijn | |
Totstandkoming releases | ToDo: tekst moet aangepast worden naar USM proces. De huidige beschrijving verwijst naar de oude situatie. | Jira ticket aangemaakt https://vzvz.atlassian.net/browse/MO-83 |
Verschillende typen releases, en correcties | Verschillende typen releases, en correcties | Versienummering van releases |
Releases voor het afsprakenstelsel worden als volgt aangeduid:
De aanduiding van releases is opgebouwd uit drie nummers, namelijk x.y.z (bijvoorbeeld 1.3.2). Bij een major release wordt de combinatie x.y opgehoogd. Daarbij zijn twee opties, ofwel y wordt met een verhoogd waarna z op 0 wordt gezet (bijvoorbeeld van 1.3.2 naar 1.4.0), ofwel x wordt met een verhoogd waarna y en z op 0 worden gezet (bijvoorbeeld van 1.3.2 naar 2.0.0). De keuze hiertussen is afhankelijk van aard en omvang van de release. Bij een minor release wordt z met een verhoogd (bijvoorbeeld van 1.3.2 naar 1.3.3). Major release vinden twee maal per jaar plaats. De inhoud van een major release wordt samengesteld op basis van uitgewerkte wijzigingsvoorstellen (RFC's). Minor releases zijn niet bij voorbaat gepland; zij worden alleen indien nodig tussen major releases uitgebracht, op een datum die in overleg met Deelnemers wordt vastgesteld. Daarnaast kunnen correcties op het MedMij Afsprakenstelsel worden aangebracht zonder dat deze leiden tot een nieuwe release. Deze doen bijvoorbeeld acute reparaties, verwijderen inconsistenties of passen voorbeeldberichten aan. Een correctie tast de juridische en technische strekking van het MedMij Afsprakenstelsel niet aan; waar dit wel het geval zou zijn, vereist de wijziging een nieuwe release. Correcties worden op een aparte pagina in het MedMij Afsprakenstelsel aangegeven. | Vanuit de NEN 7522-2021 wordt gesteld dat bij de release van een nieuwe versie van het afsprakenstelsel (artefact) deze een unieke identificatie krijgt. De door het ontwikkelteam geclassificeerde wijzigingen bepalen de unieke identificatie van de release. Voor deze unieke identificatie hanteren we SemVer versienummering. Dit is in lijn met Definitie compatibiliteit:Twee versies van het MedMij afsprakenstelsel zijn compatible met elkaar als een implementerend systeem kan overstappen van de ene naar de andere versie of gegevens kan uitwisselen met een systeem dat de andere versie implementeert, zonder dat er aanpassingen nodig zijn en zonder dat er problemen ontstaan door de wijzigingen in de nieuwe versie.
Algemene VersioneringsregelsBij het uitwerken van de wijziging wordt een analyse gemaakt om de impact van de wijziging vast te stellen.
Een release volgt de wijziging met de hoogste classificatie;
Releases voor het afsprakenstelsel worden als volgt aangeduid:
De (SemVer) aanduiding van release versienummer moet de structuur X.Y.Z. hebben, waar X, Y en Z een niet-negatief geheel getal zijn. Voorloopnullen mogen niet aanwezig zijn. X is de major, Y is de minor versie en Z is de patch-versie. Elk element moet numeriek ophogen. Bijvoorbeeld:
Hierbij geldt dat de hoogst geclassificeerde wijziging het te wijzigen nummer bepaalt. Een release candidate bevat ten minste één major wijziging en eventueel ook minors en patches. De inhoud van de nieuwe release candidate wordt samengesteld op basis van uitgewerkte wijzigingsvoorstellen. Majors worden enkel buiten de major release slots gepubliceerd indien noodzakelijk. Echter, in overleg met de belanghebbenden kunnen minors ook tussentijds doorgevoerd worden. Patches kunnen in het MedMij Afsprakenstelsel worden opgenomen zonder dat deze leiden tot een nieuwe release. Voorbeelden van patches zijn het verwijderen van inconsistenties of het aanpassen van voorbeeldberichten. Een patch heeft geen invloed op de functionaliteit en is backward compatible. Wanneer blijkt dat een patch toch invloed heeft op de functionaliteit, dient de wijziging als minor of major geclassificeerd te worden en als dusdanig behandeld te worden. | |
Besluitvorming releases | Bij major releases legt Stichting MedMij de release eerst voor aan de deelnemersraad, die hierover een zwaarwegend advies afgeeft. Het bestuur is niet gehouden aan dit advies, maar dient het advies van de raad wel serieus te nemen en een afwijking te onderbouwen. De besluitvorming over de release door het bestuur behoeft de goedkeuring van de eigenaarsraad. De eigenaarsraad dient hierbij geïnformeerd te worden over het advies van de deelnemersraad en eventueel over de motivatie van het bestuur om van dit advies af te wijken. Indien het bestuur van Stichting MedMij wijzigingen eerder wil laten implementeren dan in de releaseplanning mogelijk is, dan kan worden besloten tot invoering middels een minor release. Er wordt dan een tussentijdse release van het afsprakenstelsel gecreëerd die niet eerder was gepland. Bij minor releases is het aan het bestuur of en op welke wijze belanghebbenden worden betrokken bij de totstandkoming. Goedkeuring van de eigenaarsraad en advisering van de deelnemersraad zijn bij een minor release niet noodzakelijk. | Aan de hand van de roadmap worden wijzigingsstukken uitgewerkt. Maandelijks is er een publicatiemoment beschikbaar, hier kunnen uitgewerkte wijzigingen gepubliceerd worden. Is de wijziging geclassificeerd als patch, dan wordt deze direct doorgevoerd op de release candidate en de verplichte versie. Is de wijziging een minor of major, dan wordt tijdens de expertsessies bij de belanghebbenden consultatie gedaan voor de wijziging. Op basis van de bepaalde implementatie Bij major wijzigingen legt Stichting MedMij de voorgestelde release candidate eerst voor aan de deelnemersraad, die hierover een zwaarwegend advies
|
Implementatie releases | Zodra het besluit over een release van het afsprakenstelsel is genomen, bepaalt Stichting MedMij in overleg met de deelnemers en eigenaren welke aanpak de minste impact en verstoringen veroorzaakt. Ook maakt de stichting de afweging of releases in productie naast elkaar kunnen bestaan en of deelnemers op enig moment meerdere releases moeten ondersteunen. Voor de implementatie van de release zijn de data in de implementatieplanning bij de release leidend. Afhankelijk van het soort release kan een implementatietermijn van toepassing zijn. Stichting MedMij is ervoor verantwoordelijk dat het change- en releaseproces volgens afspraak wordt uitgevoerd, de planning te monitoren op risico's voor de afgesproken ingebruiknamemomenten, en waar nodig te escaleren op het juiste niveau. Ook zorgt zij voor een gestructureerde doorvoering van aanpassingen in de documentatie en het publiceren van een nieuwe release van het afsprakenstelsel (minimaal in de vorm van een pdf voor de administratie van deelnemers). | Als Stichting MedMij besluit tot een nieuwe release van het afsprakenstelsel, dan bepaalt zij samen met de deelnemers en de eigenaren bepaalt welke aanpak de minste impact en verstoringen veroorzaakt. Ook maakt de stichting de afweging of releases in productie naast elkaar kunnen bestaan en of deelnemers op enig moment meerdere releases moeten ondersteunen. Voor de implementatie van de release zijn de data in de implementatieplanning bij de release leidend. Afhankelijk van het soort release kan een implementatietermijn van toepassing zijn. Stichting MedMij is verantwoordelijk voor het uitvoeren van het change- en releaseproces volgens afspraak, het monitoren van de planning op risico's voor de afgesproken ingebruiknamemomenten, en waar nodig escalatie op het juiste niveau. Ook zorgt zij voor een gestructureerde doorvoering van aanpassingen in de documentatie en de publicatie van een nieuwe release van het afsprakenstelsel (minimaal in de vorm van een pdf voor de administratie van deelnemers). |
Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )
Principe's
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal |
| 11Â Stelselfuncties worden vanaf de start ingevuld |
|
2 Dienstverleners zijn transparant over de gegevensdiensten |
| 12Â Het afsprakenstelsel is een groeimodel |
|
3Â Dienstverleners concurreren op de functionaliteiten |
| 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders |
|
4Â Dienstverleners zijn aanspreekbaar door de gebruiker |
| 14Â Uitwisseling is een keuze |
|
5Â De persoon wisselt gegevens uit met de zorgaanbieder |
| 15Â Het MedMij-netwerk is gebruiksrechten-neutraal |
|
6Â MedMij spreekt alleen af wat nodig is |
| 16Â De burger regisseert zijn gezondheidsinformatie als uitgever |
|
7Â De persoon en de zorgaanbieder kiezen hun eigen dienstverlener |
| 17Â Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld |
|
9Â De dienstverleners zijn deelnemers van het afsprakenstelsel |
| 18Â Afspraken worden aantoonbaar nageleefd en gehandhaafd |
|
10Â Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling |
| 19Â Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat |
|
Toelichting |
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
---|---|---|---|---|
Bijlagen
Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |