20230111 -MO-30, Release Cycle Management
- Marlotte Pannekoek
- Yvonne Pijnacker
1. Koppelingen
1.1. Wijzigingsverzoek
1.2. Gekoppelde onderwerpen
2. Inleiding
2.1. Huidige situatie:
Twee keer per jaar (in week 18 en week 44) wordt een nieuwe versie van het afsprakenstelsel van MedMij gereleaset. In de huidige situatie wordt gewerkt met het dakpanmodel. Dit model houdt in dat altijd twee versies van het afsprakenstelsel actief zijn, namelijk één optionele en één verplichte versie. Tijdens de tweejaarlijkse release slots wordt:
de verplichte versie ingetrokken,
de optionele release verplicht en
de nieuwe optionele versie gepubliceerd.
Op dit moment zijn de versies 1.5.1 en 1.6.0 actief, hierbij is voor elke deelnemer versie 1.5.1 verplicht en versie 1.6.0 optioneel.
Voorafgaand aan het release slot wordt bepaald welke onderwerpen in de daaropvolgende release moeten worden verwerkt. Er wordt eerst bepaald welke onderwerpen moeten worden opgenomen in de volgende optionele versie, pas daarna worden deze onderwerpen uitgewerkt. We plannen dus minimaal een jaar van tevoren wat verplicht gaat worden.
2.2. Probleem
We kunnen binnen het afsprakenstelsel onvoldoende snel inspringen op de veranderende vraag uit de praktijk, doordat:
slechts twee keer per jaar een release plaatsvindt,
de release slots de ontwikkelplanning bepalen en
een jaar van tevoren al vastligt wat wordt opgenomen in het afsprakenstelsel.
Ten gevolge hiervan treden verschillende kleinere problemen op namelijk:
Nu worden wijzigingen die alsnog op korte termijn buiten de twee release slots doorgevoerd moeten worden als correcties geclassificeerd, terwijl dit eigenlijk geen correcties zijn.
Op de vaste release slots moeten zoveel mogelijk onderwerpen doorgevoerd worden.
Als er geen onderwerpen zijn om te releasen dan kunnen we alleen óf de optionele versie verplicht maken en geen wijzigingen doorvoeren voor de nieuwe optionele versie óf de release kan worden uitgesteld.
Zijn de geplande onderwerpen niet op tijd uitgewerkt voor het volgende release slot, dan kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en daardoor pas een jaar later verplicht gesteld, dit is onwenselijk omdat:
het voor sommige onderwerpen belangrijk is om deze op korte termijn op te nemen in het afsprakenstelsel. Als deze onderwerpen dus niet tijdens het geplande release slot gepubliceerd worden, dan betekent dit een vertraging van minimaal een halfjaar.
het de betrouwbaarheid van MedMij richting de deelnemers kan ondermijnen. Als wij beloven bepaalde stukken op te nemen in de optionele versie van het afsprakenstelsel en vervolgens leveren wij dit niet op dan kan dit de relatie tussen MedMij en de deelnemers schaden.
Deelnemers geven aan dat de termijn van een halfjaar tussen het opnemen in de optionele en het opnemen in de verplichte versie te kort is om impactvolle wijzigingen in het afsprakenstelsel uit te voeren.
2.2.1. Probleemstelling
Hoe kunnen wij de huidige wijze van release cycle management aanpakken zodat we beter kunnen inspringen op de continue veranderende vraag uit het dynamische Zorg ICT Landschap en MedMij zelf?
3. Doel:
Door het release cycle management aan te pakken willen we meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van stakeholders voor majors.
3.1. Subdoelen
Deelnemers en MedMij medewerkers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.
Pas de opname in het afsprakenstelsel plannen als het onderwerp al is uitgewerkt en daarmee de betrouwbaarheid richting deelnemers verhogen.
4. Scope
4.1. Binnen de scope
Deze wijziging betreft alleen het release cycle management van het MedMij Afsprakenstelsel.
4.2. Buiten de scope
Buiten de scope van deze wijziging vallen alle andere releases, denk hierbij aan de releases van nieuwe gegevensdiensten, de catalogus, updates van HL7, FHIR en ZIB's.
5. Aannames
De gekozen nieuwe release cycle wordt ondersteund door de (nieuwe manier van) versioning die nu wordt uitgewerkt.
Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.
6. Definities
Om verwarring rondom de gebruikte definities te voorkomen, wordt in deze paragraaf toegelicht welke termen gebruikt worden en welke definities eraan hangen.
Werkwoord | Moment | Omgeving | Versie |
Opnemen | Release (slot) | MM Verplicht | Verplichte versie |
Opnemen | Release (slot) | MM Optioneel | Release candidate |
Publiceren | Publicatiemoment | Change Management | Uitgewerkt(e wijzigingen) |
Voorbeeld zinnen:
Tijdens de release wordt een wijziging opgenomen in de verplichte versie in de omgeving MM Verplicht of
Tijdens de release wordt een wijziging opgenomen in de release candidate in de omgeving MM Optioneel.
Tijdens het publicatiemoment wordt een wijziging gepubliceerd op de pagina "Uitgewerkt" in de Change Management omgeving.
Term | Definitie |
Wijzigingen | Dit zijn onderwerpen die zijn uitgewerkt door MedMij Ontwikkeling om aan het afsprakenstelsel toe te voegen, om het afsprakenstelsel aan te passen of stukken uit het afsprakenstelsel te verwijderen. |
Patches | Kleine wijzigingen die geen invloed hebben op de functionaliteit en wel backwardscompatible zijn. |
Minors | Wijzigingen die wel invloed hebben op de functionaliteit en die wel backwardscompatible zijn. Geven interne en/of externe stakeholders aan dat de impact van een minor wel dusdanig groot is dat deze voor hen niet backwardscompatible is, dan wordt deze wijziging alsnog als een major geclassificeerd. |
Majors | Wijzigingen die wel invloed hebben op de functionaliteit en niet backwards compatible zijn. |
Verplichte versie | Dit is de versie waarop geaccepteerd wordt, oftewel de versie waaraan de deelnemers moeten voldoen. Deze versie wordt gepubliceerd in de confluence omgeving MM Verplicht. |
MM Verplicht | Dit is de omgeving waar de verplichte versie staat. |
Release Candidate | Deze heette voorheen de optionele versie. Dit is de versie van het afsprakenstelsel waar deelnemers aan mogen voldoen, maar hiertoe niet verplicht zijn. Deze versie wordt wel verplicht gesteld tijdens het volgende major release slot. Een nieuwe release candidate wordt alleen gecreëerd als er major wijzigingen zijn. |
MM Optioneel | Dit is de omgeving waar de release candidate zichtbaar is voor deelnemers. Deelnemers kunnen nu gaan ontwikkelen, testen en mogen nu endpoints aangaan met de R&A. |
Change management de pagina | Deze pagina bevat een overzicht van alle gepubliceerde wijzigingen voor het afsprakenstelsel die nog niet zijn opgenomen in MM Optioneel en/of MM Verplicht. |
Uitgewerkt(e wijzigingen) | Dit is de huidige versie met alle gepubliceerde wijzigingen voor het afsprakenstelsel die nog niet zijn opgenomen in MM Optioneel en/of MM Verplicht. |
Release (slot) | Tijdens het release slot kunnen wijzigingen worden opgenomen in de MM Verplicht en/of MM optioneel. Er zijn 12 release slots in een jaar, waarvan er 2 major release slots zijn. |
Major release slot | Dit zijn de 2 release slots waar majors en minors opgenomen kunnen worden in de verplichte versie en de release candidate. |
vraag
7. Gewenste situatie
De gewenste situatie is:
Meer publicatiemomenten en release slots in een jaar om zo de flexibiliteit omtrent de releases van minors en patches te verhogen.
Meer regie voor stakeholders doordat ze inspraak krijgen in de release planning, oftewel zeggenschappen over wanneer de uitgewerkte onderwerpen worden opgenomen in het MedMij Afsprakenstelsel.
Dat de wijzigingen aan het release cycle management niet de R&A processen te veel verstoren.
7.1. Usecase
De nieuwe manier van release cycle management gaat als volgt in zijn werk.
Tijdens het uitwerken van een wijzigingsstuk worden de stakeholders betrokken zodat zij alvast input kunnen leveren.
Wanneer een stuk is uitgewerkt, wordt deze besproken in de maandelijkse voorbespreking (eerste dinsdag van de maand). Hier wordt besproken of de wijziging gepubliceerd mag worden en hoeveel tijd interne stakeholders (onder andere acceptatie, ketenregie en R&A) voor implementatie nodig hebben. Deze implementatieduur wordt gebruikt om het voorkeursslot te bepalen.
Op de tweede dinsdag van de maand worden de uitgewerkte stukken gepubliceerd op de pagina uitgewerkt. Na publicatie kunnen deelnemers gaan ontwikkelen, testen en endpoints voor de R&A gaan klaarzetten, maar zij mogen deze endpoints nog niet aangaan.
Tijdens het Wijziging overleg wordt bepaald wanneer de wijzigingen worden opgenomen in MM Optioneel en MM Verplicht.
Na opname in de MM Optioneel mogen deelnemers daadwerkelijk endpoints aangaan met de R&A.
Na opname in de MM Verplicht moeten deelnemers aan deze wijzigingen voldoen en worden ze hierop ook ge-her-accepteerd.
Vraagstuk | Keuze | Toelichting |
Impact analyse | Tijdens het uitwerken van wijzigingen wordt een impact analyse uitgevoerd. Deze analyse wordt gebruikt voor de classificatie van de wijziging en het bepalen van het beste release slot voor de wijziging. | Deze impact analyse kan bevatten:
|
Publicatie frequentie Patches, Minors & Majors | Maandelijks | Elke tweede dinsdag van de maand is er een publicatiemoment waarop de uitgewerkte wijzigingsstukken in MM Uitgewerkt worden gepubliceerd. Zijn er geen uitgewerkte stukken dan wordt er niets gepubliceerd. Door maandelijks een publicatiemoment beschikbaar te hebben kunnen wijzigingen direct na afronding gepubliceerd worden, deelnemers eerder zien welke onderwerpen eraan komen en wijzigingen eerder worden opgenomen in het afsprakenstelsel. Doordat deelnemers voorafgaand aan het wijziging overleg al de stukken kunnen inzien, zijn zij in staat alvast de impact van de wijziging en hun gewenste release slot te bepalen. Verder kunnen deelnemers eerder beginnen met ontwikkelen, testen en het klaarzetten van de nieuwe endpoint met de R&A. Verder kunnen deelnemers beter hun ontwikkelplanningen maken en bijsturen als ze eerder inzicht hebben in welke wijzigingen aan het afsprakenstelsel eraan komen. |
Classificatie van wijzigingen | Bij uitwerking van de wijziging wordt een inschatting gemaakt voor de classificatie. Tijdens de voorbespreking wordt de wijziging geclassificeerd. | Een uitgewerkte wijziging wordt geclassificeerd als major, minor of patch op basis van de onderstaande punten: - of het de uitwisseling beïnvloedt/ backwardscompatible is met het huidige afsprakenstelsel Blijkt tijdens het wijziging overleg dat de impact van een minor groter is dan vooraf ingeschat, dan kan de minor alsnog als major geclassificeerd worden. |
Publiceren Wijzigingsstukken voor opname in MM Optioneel? | Ja, op pagina Uitgewerkt | In het openbare deel van de 'MedMij Afsprakenstelsel Change Management' omgeving komt de confluence pagina 'Uitgewerkt' te staan, hier staat een overzicht van alle uitgewerkte wijzigingsstukken met tenminste de volgende informatie:
Deze uitwerkingen zijn inzichtelijk voor alle deelnemers. Aan de hand van de uitgewerkte wijzigingen kunnen stakeholders bepalen of ze willen aansluiten bij het wijziging overleg. |
Behoud optionele versie | Ja, maar gaat release candidate heten | De processen voor R&A beheer en release cycle management zijn nauw verweven. De inrichting van de R&A is namelijk gebaseerd op het dakpanmodel. Je kan het dakpanmodel dus niet loslaten zonder de R&A opnieuw te moeten inrichten. In eerste instantie wordt het release cycle management wel gewijzigd, maar blijft het dakpanmodel wel behouden. Op een later moment wordt geëvalueerd of herinrichting van de R&A en verder herstructureren van het release cycle management wenselijk is en zo ja hoe dit wordt vormgegeven. |
Voorbespreking | Maandelijks | De voorbespreking is intern. De volgende partijen zijn ten minste uitgenodigd:
Agenda:
Is er overeenstemming bereikt over de stukken dan worden deze op de dinsdag van de daaropvolgende week gepubliceerd op pagina "Uitgewerkt". |
Wijziging Overleg | Bij voorkeur 4x per jaar, maar voorlopig in lijn met de geplande expertsessies | Bij het wijziging overleg wordt samen met alle stakeholders voor de minors en majors bepaald tijdens welk release slot de wijziging wordt opgenomen in het afsprakenstelsel. Om te worden meegenomen in het wijziging overleg moeten de stukken minimaal 1 week van tevoren gepubliceerd zijn. Deze overleggen vinden minimaal één maand voor het major release slot plaats. Bij voorkeur vinden de wijziging overleggen eens in de 3 maanden plaats, omdat deze overleggen worden gecombineerd met de expert sessies vinden deze niet plaats in de zomer. Uitgenodigd zijn:
Tijdens het stakeholder overleg worden de volgende punten besproken:
De inspraak van de stakeholders is wel dusdanig beperkt dat ze de opname van het stuk in het afsprakenstelsel niet oneindig uit kunnen stellen. |
Creëren nieuwe release candidate | Alleen bij majors | Alleen majors leiden tot een nieuwe release candidate. Is er een major wijziging uitgewerkt en willen we deze opnemen in de verplichte versie dan moet deze eerst 6 maanden in de release candidate staan. |
Wanneer release candidate vaststellen voor release | Minimaal 1 maand voor het Major release slot | Tijdens het wijziging overleg wordt een voorstel gedaan voor de samenstelling van de volgende release candidate. Deze voorgestelde release candidate gaat naar de deelnemersraad die hier een advies over uitgeeft aan het MedMij bestuur. Het bestuur neemt een besluit over de release candidate en dit besluit wordt ter goedkeuring aan de eigenaarsraad voorgelegd. Is de voorgestelde release candidate goedgekeurd dan wordt deze tijdens het volgende major release moment opgenomen in de MM Optioneel omgeving als de nieuwe release candidate. |
Release slot a. Patches b. Minors c. Major | a. Patches 1x p.m. b. Minors 2x p.j. In overleg met stakeholders kan opname ook buiten de twee major release slots. c. Majors 2x p.j., tenzij het wegens een wetswijziging of security risico vereist is om buiten de release slots de Major in het Afsprakenstelsel op te nemen. | Release slots bieden de optie tot een release. Er is geen verplichting om een nieuwe versie te op te nemen in het afsprakenstelsel. a. Voor patches zijn er 12 release slots in een jaar. Patches worden direct doorgevoerd op zowel de release candidate als de verplichte versie. De verwachting is dat patches weinig invloed hebben op de stakeholders en dat planning van het release slot voor de patch dus onnodig is. Door de release slots voor patches maandelijks te laten plaatsvinden is het mogelijk om kleine aanpassingen op korte termijn door te voeren. b. In principe worden minors alleen opgenomen in het afsprakenstelsel tijdens de twee major release slots per jaar. In overleg met de stakeholders kan hiervan worden afgeweken en kan er tussentijds een minor release op beide versies plaatsvinden. Zo is er duidelijkheid voor alle stakeholders, maar blijft de mogelijkheid behouden om (indien gewenst) op korte termijn wijzigingen door te voeren. c. Majors worden slechts twee keer per jaar doorgevoerd, namelijk tijdens de major release slots (tweede dinsdag van april en oktober). Als het noodzakelijk is kan hiervan worden afgeweken, bijvoorbeeld bij een wetswijziging of een security risico. |
Uitfaseren stukken afsprakenstelsel | Het uit te faseren stuk wordt geclassificeerd. a. Patches, tijdens het publicatie slot wordt het stuk direct verwijderd uit beide versies. b. Minor en Major, i.o.m. stakeholders wordt het slot bepaald. | a. Is het te verwijderen stuk een patch dan kan het stuk direct na publicatie verwijderd worden uit de release candidate en de verplichte versie. b. Betreft het te verwijderen stuk een minor of major dan wordt deze wijziging gepubliceerd op de pagina "Uitgewerkt". Tijdens het wijziging overleg wordt bij de stakeholders opgehaald hoeveel tijd zij nodig hebben voor uitfasering. Een halfjaar voor het gekozen release slot wordt het stuk verwijderd uit de release candidate. Deelnemers hebben vanaf dat moment 6 maanden voor uitfasering. De periode tussen het aanpassen van de release candidate en de verplichte versie is dan ook de officiële de periode van uitfasering. |
Risico's | a. Onvoldoende deelname aan overleggen b. Impactbepaling | a. Een risico is dat niet genoeg stakeholders (m.n. deelnemers) deelnemen aan de overleggen, waardoor wijzigingen worden doorgevoerd op te korte termijn en dit voorkomen had kunnen worden als de juiste stakeholders aan tafel hadden gezeten. b. Het tweede risico betreft in hoeverre wij samen met de stakeholders in staat zijn om vooraf goed te bepalen wat de impact van bepaalde wijzigingen en/of onderwerpen gaat zijn. |