Een nieuwe release...

Naomi van de servicedesk vertelt Vijf keer per jaar leveren we een major release uit als ANVA. Net als de meeste jaren is de grootste en spannendste de release van augustus. Als hij zo groot en spannend is, hoe zorgen we er dan voor dat we als servicedesk met vertrouwen kunnen zeggen: "Natuurlijk kun je overstappen naar onze nieuwe release, sterker nog: we raden het je aan!". In deze blog geef ik jullie een kijkje in de keuken van het releaseproces. Ik ga dit doen aan de hand van de 51.P03.10. De release van augustus. Zo kan ik direct de kans pakken om nog wat informatie te delen over de inhoud van deze release.

Wat komt er in de release?

Voorheen werkten er meerdere teams, maar één Product Owner aan nieuwe functionaliteiten voor ANVA 4/5. Tegenwoordig zijn dat drie of vier Product Owners met hun teams. Als team wil je dat nieuwe functionaliteiten zo snel mogelijk bij klanten in productie staan. Klanten die er in productie mee werken geven immers de beste feedback. Hoe eerder deze feedback bij ons terecht komt, hoe beter de code nog in ieders hoofd zit. Als de feedback later volgt zijn de ontwikkelaars al met de volgende functionaliteit bezig en kost het meer tijd om de feedback te verwerken.

Nu er meer teams functionaliteiten bouwen, moeten we heel goed afstemmen wanneer een release uitkomt. Wanneer is alles geschikt om uit te leveren? Overlappen functionaliteiten elkaar? Wat vraagt het van onze klanten? Allemaal vragen die ik samen met de Product Owners doorneem, voordat we definitief besluiten wat er in een release komt.

Zo ook voor de 51.P03.10. Drie Product Owners hebben nieuwe functionaliteiten opgeleverd met hun teams. Na goed overleg is er voor gekozen om alle functionaliteiten in de 51.P03.10 te stoppen. Daarbij hebben we genoteerd dat dit meer vraagt van onze testen en dat we extra goed moeten communiceren met jullie als klant. Het alternatief was om de functionaliteiten te verspreiden over meerdere releases. Dan zit er minder risico op fouten in de 51.P03.10, maar komt de feedback voor sommige teams veel later. Ook moeten jullie als klant dan langer wachten op functionaliteiten waar wel degelijk grote behoefte aan is.

 

Testen, testen, testen

Ieder stukje code wat we schrijven word getest. Maar als meerdere teams functionaliteiten ontwikkelen die in één release komen, moeten we meer testen. Dan is de test van de individuele functionaliteiten niet genoeg. Want werkt alles ook nog als het bij elkaar komt? En wat heeft het voor impact op reeds bestaande software? Kan die geraakt zijn?

Onze ANVA 4/5 software is ruim 20 jaar oud. In die jaren is er heel veel bijgemaakt, ook specifieke software voor individuele klanten. Intern zeggen we wel eens dat we in de kern van de applicatie, die stabiel werkt, een spaghetti hebben gecreëerd. Iets wat testen soms lastig en onvoorspelbaar maakt.

Sinds dit jaar testen we dan ook niet alleen de code en de standaard testscripts. Als servicedesk en consultants doen we ook gebruikerstesten. Wij weten namelijk als geen ander hoe de software wordt gebruikt, ook dat moet worden getest. Door dit te filmen en te delen met onze teams gaan we kijken of we deze testen kunnen automatiseren of later ook door de teams uit kunnen laten voeren. Zo investeren we iedere release om het testen van de volgende release nog vollediger te doen. Dit zorgt voor een steeds betere kwaliteit. Wat een vertrouwder gevoel moet opleveren bij jullie als klant en waardoor nieuwe updates sneller geïnstalleerd worden in productie. Immers: des te sneller nieuwe functionaliteiten in productie staan, des te sneller hebben we feedback en des te makkelijker kunnen we de feedback verwerken.

Releasebrief

Tijdens het hele voorgaande proces zijn onze schrijvers al druk bezig met het opzetten van de releasebrief. Dit is dé manier voor jullie als klant om te zien wat er in een release wordt uitgeleverd. Moet er misschien nog inrichting worden aangepast? Neemt het geheugengebruik toe? Zitten er gave nieuwe dingen in, of worden er functionaliteiten uit gefaseerd? Er wordt allemaal bij stil gestaan en beschreven.

Als de releasebrief is afgerond lezen alle betrokken Product Owners nog een keer mee. Daarna wordt er met de functionele teams van de servicedesk door de releasebrief heen gelopen. Welke vragen zouden klanten hier nog over kunnen stellen? Kunnen we iets doen om die vragen te voorkomen? Hebben we zelf wel alle kennis die nodig is? Alles om goed voorbereid te zijn op de uitlevering van de nieuwe release. Zo bouwen wij voor onszelf vertrouwen op en kunnen we beter inschatten voor welke klanten de impact van installatie groter gaat zijn dan bij andere. We weten namelijk steeds beter welke klanten welke software gebruiken, hoe groot ze zijn en wat de impact op hun gebruikers is. Iets wat tijd kost, maar waar we enorm trots op zijn!

Informeren

In het geval van de 51.P03.10 hebben we als servicedesk besloten dat alleen de releasebrief niet genoeg is. We willen jullie als klanten meer informatie geven. Wat gaat er aan komen, waar zitten de risico’s, wat is ons advies? De eerste mail hebben we een maand voor het beschikbaar stellen van de kandidaatrelease al verstuurd. Voordat we een major release uitleveren, maken we altijd eerst een kandidaatrelease. Deze wordt wel in productie geïnstalleerd door klanten, maar lang niet door iedereen. Wanneer de kandidaatrelease geen problemen oplevert zetten we die om naar de major release. Komen er wel problemen uit? Dan kunnen we die direct oplossen en uitleveren in de major release. In de mail die we hebben gestuurd stond de planning van de kandidaatrelease, pilots en major release en informatie over alle nieuwe functionaliteiten.

Veel van jullie willen vanaf september geen nieuwe release meer installeren. Dan zijn de voorbereidingen op de prolongatie van januari begonnen en is er geen capaciteit en vertrouwen dat een nieuwe update daar geen invloed op gaat hebben. Hier proberen we steeds meer rekening mee te houden.  De release komt op 1 augustus beschikbaar, zo is er tijd voor testen en installeren bij onze klanten. Nu zit er bijvoorbeeld een oplossing in voor mailauthenticatie. Dat moet vóór 1 oktober in productie staan als je werkt met Office365. Hoe later wij die release uitleveren, hoe moeilijker het wordt om alle klanten tijdig over te hebben.

Installeren en uitleveren

Na het testen, schrijven van de releasebrief en het informeren van klanten gaan we de release bouwen. Dan volgt er nog een laatste test door onze technische collega’s en de servicedesk. Namelijk het daadwerkelijk installeren van de release. Dit doen we op verschillende interne omgevingen, zowel Windows als Linux.

Omdat er in de 51.P03.10 een nieuwe JBoss versie zit, en we zeker wilden weten dat de installatie goed zou gaan, hebben we ook installaties bij klanten uitgevoerd. Klanten die altijd snel een update installeren hebben we gevraagd of ze ook nu mee willen doen. We hebben ze aangeboden dat wij de installatie uitvoeren. Pas na negen installaties en één week draaien in productie hebben we ervoor gekozen om de releasekandidaat 51.P03.01 voor iedereen beschikbaar te stellen. Iets wat ons goed is bevallen. We hebben zelf nu nog meer vertrouwen in de release en kunnen dat delen met al onze klanten.

Een week na het vrijgeven van de 51.P03.01 hebben we opnieuw al onze klanten een mail gestuurd. Hierin stond de status en alle bevindingen tot dan toe. Het aantal bevindingen viel gelukkig heel erg mee. We kunnen daarom nog steeds vasthouden aan onze planning en verwachten de 51.P03.10 op 1 augustus voor iedereen beschikbaar te hebben.

Ik ben blij dat we als servicedesk een grote rol hebben in het proces. Zo kunnen we vertrouwen opbouwen en uitstralen. We kunnen de juiste manieren van communiceren bepalen en iedereen meenemen. Zo gaan we steeds meer kwaliteit toevoegen en jullie als klant steeds beter meekrijgen naar actuele releases. Ook voor dit proces geldt dat ik altijd open sta voor vragen en tips, dus mail of bel gerust na het lezen van deze blog.

Schrijf je in voor onze nieuwsbrief!

Blijf op de hoogte van de laatste nieuwtjes en schrijf je in voor de ANVA nieuwsbrief