...
- Releasecyclus
- Dakpansgewijze releases
- Totstandkoming releases
- Verschillende typen releases, en correcties
- Besluitvorming releases
- Implementatie releases
Het MedMij Afsprakenstelsel evolueertAfsprakenstelsel ontwikkelt zich voortdurend. Ontwikkelingen binnen en rondom MedMij kunnen aanleiding geven om afspraken uit het stelsel te wijzigen.
...
Om het ritme van de voortdurende ontwikkeling van het MedMij Afsprakenstelsel voor Deelnemers zo voorspelbaar mogelijk te maken, en Deelnemers daarbinnen ruimte te geven voor een proactief of reactief implementatiebeleid, zijn er op elk moment twee releases van het MedMij Afsprakenstelsel actief. Alleen actieve releases mogen actief zijn binnen het operationele MedMij-netwerk. Van die twee actieve releases is er altijd één verplicht en de andere is optioneel. Dat wil zeggen dat alle Deelnemersop deze verplichte versie moeten ondersteunen. De andere actieve release heet de release candidate. Implementatie daarvan is niet verplicht, maar wel toegestaan binnen het operationele MedMij-netwerk. Omdat de Interfaces, Gegevensuitwisseling, Core in het MedMij Afsprakenstelsel geversioneerd zijn, kunnen deze tegelijkertijd actief zijn. De gepubliceerde release is de opvolger van de verplichte. Elke Deelnemer kiest zelf wanneer hij de gepubliceerde versie implementeert, desgewenst naast de verplichte.
...
Ook op de Gegevensdiensten is dakpansgewijs releasen van toepassing. Dit staat beschreven in het Gegevensdienstenbeleid.
Implicaties voor NEN-certificering
Met de publicatie van een nieuwe versie van het Afsprakenstelsel komt er ook een nieuw aanvullend normenkader beschikbaar. Om een balans te hebben tussen de benodigde tijd die deelnemers nodig hebben voor het maken van aanpassingen enerzijds, en het (te) lang moeten wachten met het verscherpen van de normen rond beveiliging anderzijds, wordt een periode van vier maanden in acht aangehouden voordat de nieuwe versie van het aanvullende normenkader toegepast wordt in de NEN certificatie. Dit betekent dat de gepubliceerde versie van het aanvullend normenkader eerder verplicht en algemeen wordt dan de overige delen van het Afsprakenstelsel.
...
Alle belanghebbenden, waaronder in ieder geval de deelnemers, gebruikers en Stichting MedMij, kunnen invloed uitoefenen op (de totstandkoming van) wijzigingen in het afsprakenstelsel. Een Request For Change (RFC) kan door een belanghebbende, voorzien van motivatie, worden ingediend voor behandeling. Stichting MedMij doet een eerste beoordeling van ingediende RFC's, door deze te toetsen aan de vigerende geldende wet- en regelgeving, architectuur en grondslagen, strategische koers, het jaarplan en de releasekalender. Hierbij wordt onder andere beoordeeld of het daadwerkelijk gaat om een wijziging, of de wijziging niet al eerder is ingediend en wat de urgentie is. Stichting MedMij zorgt, indien waar nodig, voor de nadere verkenning van RFC's door wijzigingsverzoeken te laten uitwerken, de benodigde expertise en vertegenwoordiging bij elkaar te brengen, de afstemming met partijen rondom het stelsel te kanaliseren, te zorgen dat de impact voor een impactanalyse van een wijziging op het stelsel. Dit onderzoeken we samen met de deelnemers, en indien nodig wordt een business case opgesteld samen met betrokkenen. en de deelnemers wordt onderzocht en indien nodig een business case wordt opgesteld met betrokkenen. Ook controleert zij Ook controleert Stichting MedMij of de voorgestelde oplossing vrij en kosteloos voor de deelnemers te gebruiken is.
In principe mogen betrokkenen bij het ontwikkelproces ontwikkelinformatie vrij met elkaar delen zonder aanvullende bescherming. Alleen voor informatie over kwetsbaarheden geldt dat verspreiding beperkt is tot de direct betrokkenen en alleen mag plaatsvinden met extra bescherming (zie Informatieclassificatiebeleid). Mochten belanghebbenden gedurende het change- en releaseproces bijdragen aan de uitwerking van een wijziging, dan ziet Stichting MedMij erop toe dat zij over de juiste auteursrechten komt te beschikken om de documentatie te kunnen publiceren (zie Intellectueel eigendomsbeleid).
Het afsprakenstelsel bestaat uit een samenhangende set van producten (juridisch kader, overeenkomsten, architectuur en technische specificaties, etc.) met veel onderlinge afhankelijkheden. Aanpassing van een één van de onderdelen vraagt altijd om een impactanalyse op de rest van de producten. Het afsprakenstelsel wordt daarom altijd in haar geheel gereleaset. Deze releases bestaan uit een consistente set van RFC's en kunnen daarnaast verbeteringen van niet-inhoudelijke aard bevatten.
...
Versienummering van releases
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 het Nictiz gegevensdienstversienummer beleid.
Definitie van 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 met de andere versie, zonder dat er aanpassingen nodig zijn en zonder dat er problemen ontstaan door de wijzigingen in de nieuwe versie.
- Als een nieuwe versie compatible is met een eerdere versie, dan wordt er gesproken over backward compatibility.
Algemene Versioneringsregels
Bij het uitwerken van de wijziging wordt een analyse gemaakt om de impact van de wijziging vast te stellen. Een uitgewerkte wijziging wordt geclassificeerd als major, minor of patch o.b.v. de onderstaande onderdelen:
- of het de uitwisseling beïnvloedt en daarmee niet backward compatible is met het huidige afsprakenstelsel
- of en hoe het de functionaliteit beïnvloedt
- of het alleen een tekstuele wijziging is zonder functionele invloed
Een release volgt de wijziging met de hoogste classificatie;
- Een incompatibele wijziging leidt ALTIJD tot een major publicatie
- Een compatibele wijziging KAN, met valide reden, ook tot een major publicatie leiden (bijvoorbeeld door grote impact op de uitwisselingsketen).
Releases voor het afsprakenstelsel worden als volgt aangeduid:
- Major
...
- :
...
- wijzigingen die invloed hebben op de functionaliteit en niet backward compatible zijn. Deze releases worden opgenomen in de
...
- roadmap;
- Minor
...
- :
...
- Wijzigingen die nodig zijn om een onmiddellijke dreiging voor de continuïteit van of het vertrouwen in het MedMij Afsprakenstelsel/-netwerk af te wenden;
- Verbeteringen waarvan de baten van spoedig doorvoeren significant groter zijn dan de implementatie-inspanningen, en die op breed draagvlak onder de deelnemers kunnen rekenen.
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.Er zijn twee major releases per jaar. 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 nodigals dit nodig is tussen major releases uitgebracht, op een datum die in overleg met Deelnemers wordt vastgesteld.
...
- wijzigingen die invloed hebben op de functionaliteit en backward compatible zijn;
- Patch: Wijzigingen die geen invloed hebben op de functionaliteit en backward compatible zijn.
De (SemVer) aanduiding van het 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:
- Patch 1.6.0 => 1.6.1
- Minor 1.6.0 => 1.7.0
- Major 1.7.0 => 2.0.0
Hierbij geldt dat de hoogst geclassificeerde wijziging het te wijzigen nummer bepaalt.
Een release candidate bevat tenminste éé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.
...
Besluitvorming releases
...
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
Aan de hand van de roadmap worden wijzigingsstukken uitgewerkt. Maandelijks is er een publicatiemoment beschikbaar waar 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 implementatietijden van de wijzigingen wordt een voorstel gedaan voor de volgende release candidate.
Bij major wijzigingen legt Stichting MedMij de voorgestelde release candidate eerst voor aan de Deelnemersraad, die hierover een zwaarwegend advies
...
mag afgeven. Het bestuur is niet gehouden aan dit advies, maar
...
moet het advies van de raad wel serieus
...
nemen en een afwijking
...
onderbouwen. De besluitvorming over de nieuwe release door het bestuur
...
heeft de
...
goedkeuring nodig van de
...
Eigenaarsraad. De
...
Eigenaarsraad moet hierbij geïnformeerd worden over het advies van de
...
Deelnemersraad en
...
de
...
eventuele motivatie van het bestuur om van dit advies af te wijken.
...
Als het bestuur van Stichting MedMij
...
minors eerder wil laten implementeren dan
...
het beoogde major release slot, dan kan in overleg met het bestuur en de belanghebbenden worden besloten de minors op één van de reguliere release slots tussentijds door te voeren. Bij een minor release zijn goedkeuring van de eigenaarsraad en advisering van de deelnemersraad niet noodzakelijk.
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. 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 ervoor verantwoordelijk dat voor het uitvoeren van het change- en releaseproces volgens afspraak wordt uitgevoerd, het monitoren van de planning te monitoren op planning op risico's voor de afgesproken ingebruiknamemomenten, en waar nodig te escaleren escalatie op het juiste niveau. Ook zorgt zij voor een gestructureerde doorvoering van aanpassingen in de documentatie en het publiceren de publicatie van een nieuwe release van het afsprakenstelsel (minimaal in de vorm van een pdf voor de administratie van deelnemers).