Releases en patches

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

3 reacties / 0 nieuw
Gilbert Frijters
Releases en patches

Op 14 mei 2014 hebben we een stevige discussie gehad over de releases en patches. Ik hoop dat iedereen heeft begrepen dat dit over de inhoud en niet over de persoon is gegaan. Mocht dat verkeerd over zijn gekomen dan bij deze daarvoor mij excuus. Naar mijn idee zijn er twee verschillende trajecten door elkaar gaan lopen die los van elkaar gezien moeten worden. Dit ondanks dat ze een grote relatie naar elkaar hebben. Naar mijn idee zijn er twee verschillende trajecten, de eerste is het reguliere release en patch beleid en de tweede is het onderdeel winstpakker gemeenten. Wat er precies in een release of in een patch hoort te zitten is volgens mij redelijk duidelijk, mocht dat niet het geval zijn dan is dat een onderdeel waar we het zeker nog een keer over moeten hebben? Mijn voorstel zou zijn om vast te houden aan twee releases op jaarbasis. Bijvoorbeeld één in oktober een één in april, patches kunnen naar mijn idee op ieder moment komen maar dienen uiteindelijk altijd in een release opgelost te worden. Daarbij maak heb ik wel de volgende vraag, stel nu dat in oktober er geen release uit komt omdat we geen release waardige verbeteringen hebben. Patches zijn er nagenoeg zeker, willen we dan toch een release uitbrengen waarin de patch punten zijn verwerkt? Waarom dit zorgpunt? Gemeenten hebben net als leveranciers een beleid over hoe om te gaan met releases en patches. Daarbij wordt regelmatig het beleid gevoerd om één release achter te lopen. Dit heeft als voordeel dat er vaak behoorlijk wat patches overgeslagen kunnen worden wat weer tijd en geld scheelt. Van dit beleid wordt vaak alleen afgeweken indien er een probleem optreedt wat tot productiebelemmeringen leid. Door geen release uit te brengen worden deze gemeenten gedwongen tot veel testwerk, installatiewerkzaamheden enz. Zeker de wat kleine gemeenten kunnen daar behoorlijk mee in de problemen komen, zij hebben veel werkzaamheden en weinig mensen op deze uit te voeren. Daardoor is het voor hen van belang dat ze goed kunnen plannen. Het plaatsen van releases is goed te plannen, dit in tegenstelling tot het plaatsen van patches. Dit is veelal adhoc werk wat tussendoor moet. Ik maak me daarbij dus behoorlijk zorgen over deze gemeenten of zij dit wel aan kunnen? Dan het onderdeel winstpakker gemeenten. Als winstpakker gemeenten gaan we behoorlijk voorop lopen. Dit houdt in dat we een intentieverklaring ondertekenen en daarbij een verplichting aangaan. Als gemeente Westland gaan we dit op het hoogste niveau doen wat wil zeggen dat we de intentieverklaring door de verantwoordelijk wethouder, directie Centric, directie BCT en directie van KING laten ondertekenen. Mijn zorg zit hem in dit onderwerp in de mogelijkheid dat als we tegen problemen aan lopen we eerst alle leveranciers zouden moeten consulteren voordat we een eventuele oplossing kunnen implementeren. Een andere zorg die ik daarbij heb is dat we, als we niet jullie allemaal consulteren, niet de optimale oplossing kiezen. Wat ik echter wil voorkomen is dat ik aan een aantal directies moet gaan vertellen dat we niet aan de afspraken kunnen voldoen omdat er niet voldoende reactie is van de andere leveranciers. De opmerking die ik daarbij zeker ga krijgen is dat we niets met deze leveranciers te maken hebben omdat we daar geen producten van af hebben genomen. Eigenlijk is de vraag in deze dan ook of ook jullie commitment willen geven aan wat wij, Woerden en eventuele andere winstpakker gemeenten gaan doen? Daarbij zullen we afspraken moeten maken over de termijn waarop reactie gegeven kan worden op de voorstellen. Dit om te voorkomen dat de winstpakker gemeenten aan hun directie moeten mededelen dat ze niet aan de afspraken kunnen voldoen. Zoals Virginia (ik hoop dat ik de naam goed schrijf) al aangaf zijn de winspakker gemeenten in deze een op zichzelf staand onderwerp en wijkt dat behoorlijk af van de beheerfase waar we allemaal zo graag naar toe willen. Ik hoor graag hoe jullie hier in staan en of jullie mijn zorgen weg kunnen nemen? Groet, Gilbert.

Jan Campschroer

Volgens mij hebben we nu het volgende afgesproken in de werkgroep. Bij de winstpakkers staat de (winstgevende) verandering bij de gemeente voorop. Als blijkt dat iets niet werkt omdat het fout is, dan moet je daar (in die gemeente in ieder geval) een oplossing voor bedenken. En zoals je aangeeft, moet dat meestal ook snel gebeuren. Vandaar de regel: Heb je een fout, beschrijf die op de GEMMA-community en geef er ook een oplossing bij (en liefst ook de mogelijkheden die je verworpen hebt) met de argumenten vóór en tegen. Als er binnen 2 weken geen reactie is, dan is het (voor anderen blijkbaar nog) niet belangrijk. Dan kun je de voorgestelde oplossing gewoon doorvoeren. Ook als de reacties alleen instemmend zijn, kun je gewoon doorvoeren. Komt er wel een tegenreactie dan zullen we daar met zijn allen aan moeten werken om die snel op te lossen. D.w.z. tot consensus te komen. (Gestructureerd de dialoog voeren is daarbij belangrijk. Daar kunnen we met zijn allen nog wel wat in leren. :-) ). NB: we moeten nog wel kijken of dit werkbaar is. Bijvoorbeeld of die twee weken een goede periode is. Na aanpassing voldoe je in principe niet meer aan de standaard. Zaak (voor KING en degene die deze oplossing heeft bedacht) is om in de eerstvolgende publicatie van de standaard (en dat kan een paar maanden later zijn) de (lokaal gekozen) oplossing mee te nemen. Die lokaal gekozen oplossing moet dan nog wel goedgekeurd worden. Je hoeft dus niet te wachten op de patch van de standaard. Je kunt al wel een lokale patch maken van de applicatie(s) die -als het allemaal goed gaat- in feite later weer gestandaardiseerd wordt. Daar loop je dus wel een risico. We hebben daarbij de volgende aandachtspunten: - Als anderen tegen hetzelfde probleem aanlopen (ze houden zich tenslotte wel aan de standaard) moeten ze dezelfde oplossing implementeren. We lopen hier het risico dat het daar toch iets anders is. Daar zullen we dan uit moeten zien te komen, waarbij we als extra hindernis hebben, dat er al iemand een (niet afgekeurde, maar ook nog niet officieel goedgekeurde) oplossing heeft geïmplementeerd. De voorloper moet niet gestraft worden! - We moeten "wildgroei" voorkomen: - Waar problemen vergelijkbaar zijn, moeten we vergelijkbare oplossingen nemen. Hiervoor zijn designpatterns en ontwerpprincipes belangrijke instrumenten. Mogelijk moeten we die hier en daar meer expliciet maken. - Functionaliteit moet je maar op één manier implementeren. Betekent wel dat je helder moet hebben wat de functionaliteit (concreet en ook in detail) is. Is dit werkbaar?

Gilbert Frijters

Naar mijn idee is deze manier redelijk goed werkbaar. Niet optimaal, maar gezien de omstandigheden is een opitmale oplossing ook niet goed mogelijk.