Hoe ik mijn releases voorbereid en test
Releases en releasebeheer vormen een essentieel onderdeel van ons werk. Door het juiste product aan de klanten te leveren, maken we hen blij. Een soepel verloop van de release maakt ons, degenen die bij de release betrokken zijn, blij.
Hoe kunnen we een soepele release bereiken?
Omdat ik aan een groot aantal releases heb deelgenomen, kan ik zeggen dat er een paar belangrijke punten zijn die kunnen helpen bij succesvol releasebeheer.
Laat me vertellen welke dat zijn.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Een succesvolle release begint tijdens de ontwikkeling.
Testgevallen identificeren
Goed releasebeheer begint al lang vóór de dag van de release, vanaf het moment dat de te releasen functie zich in de ontwikkelingsfase bevindt. In deze periode moet voor de functie goedkeuring door QA worden gegeven. Dit betekent dat we alle mogelijke scenario's die we kunnen bedenken en die relevant zijn voor de betreffende functie, moeten testen om te valideren dat de functie volgens de vereisten werkt. Sommige van deze scenario's worden getest met geautomatiseerde tests, terwijl het voor sommige scenario's te moeilijk of niet de moeite waard is om automatisering te creëren.
Wanneer we bepalen welk type testen we voor de betreffende functie moeten uitvoeren, moeten we het volgende overwegen: de eerste keer dat deze functie naar productie gaat, moeten we deze volledig testen. We moeten ervoor zorgen dat de klanten geen kritieke problemen zullen ontdekken. We moeten de vereisten valideren. En we moeten zorgen voor goede prestaties van de functie.
Vertragingen en problemen bij het testen kunnen de planning ernstig beïnvloeden bij de voorbereiding van software-releases. Door effectieve praktijken voor releasebeheer toe te passen, blijft het testen en implementeren betrouwbaar en voorspelbaar.
Maar zodra de functie live is gegaan, hoeven we deze niet bij elke toekomstige release van dezelfde codebasis zo grondig te testen, tenzij er updates voor nodig zijn. Het gedrag van de functie verandert alleen als de onderliggende code is gewijzigd of als er een externe wijziging heeft plaatsgevonden in een van de afhankelijkheden die de functie gebruikt. De rest van de tijd volstaat een controle van de basisfunctionaliteit van de functie, waarbij deze controle uiteraard de belangrijkste testgevallen omvat.
Dat gezegd hebbende, moet je tijdens de ontwikkeling van de functie nagaan: hoeveel testgevallen je moet testen; hoeveel tijd je beschikbaar hebt voor het testen; welke testgevallen kritiek zijn; welke testgevallen je bij elke release zou uitvoeren.
Op deze manier kun je bepalen welke testgevallen je zult automatiseren. Richt je erop om ten minste de kritieke functionaliteit met automatisering af te dekken. Voor de overige tests moet je schriftelijke testgevallen maken in je projectvolgsysteem (bijvoorbeeld Jira) of in de tool voor testbeheer die je gebruikt. Zo raken ze niet zoek of worden ze niet vergeten en kunnen ze worden uitgevoerd wanneer een release dat vereist.
De tests uitvoeren in de CI
Zodra je over geautomatiseerde tests beschikt, moet je deze periodiek via de CI uitvoeren in de ontwikkelomgevingen. Terwijl er vóór de release andere functies worden ontwikkeld, is het goed om te controleren of de functie die je wilt releasen nog steeds goed werkt, vooral als je deze tijdens de sprint al hebt goedgekeurd. Door de tests voor de functie waarin je geïnteresseerd bent, bijvoorbeeld dagelijks, uit te voeren, krijg je snel feedback over eventuele oplossingen die op de functie moeten worden toegepast voor fouten die door andere wijzigingen in het systeem worden veroorzaakt.
Vroegtijdige detectie van mogelijke fouten in de te releasen functie geeft voldoende tijd om de oplossingen toe te passen en de functie opnieuw te testen, zonder de stress om dit te moeten doen binnen de beperkte tijd die je in de releasefase hebt. Hoe meer van de vereisten je met je geautomatiseerde tests afdekt, hoe groter de kans dat je in de releasefase slechts een klein aantal fouten zult vinden.
Preproductie is belangrijk en moet een ingebouwde buffer hebben.
Tijdvensters
De releasefase bestaat doorgaans uit een periode die is gereserveerd voor het testen in een preproductie-integratieomgeving, naast de dag of periode van de productierelease. Als tester die bij de release betrokken is, vraag ik altijd om passende tijdvensters voor de release, zodat de preproductiefase mij in staat stelt de te releasen functies goed te testen.
Ik houd ook altijd rekening met buffertijd, omdat ik verwacht dat er tijdens het releasebeheerproces onvoorziene problemen zullen optreden, of het nu gaat om fouten in de te releasen functies of om externe factoren. Om een van deze factoren te noemen: preproductieomgevingen zijn testomgevingen en het risico bestaat dat ze niet zo betrouwbaar zijn als ze zouden moeten zijn. Vaak werken ze juist tijdens het uitvoeren van de releasetests zeer traag of zijn ze enige tijd niet beschikbaar.
Extra buffertijd inbouwen is altijd een goed idee, en zelfs als je die extra tijd niet gebruikt, is dat prima. Je kunt je goedkeuring geven voordat de toegewezen testtijd voorbij is, omdat je de resterende tijd aan iets anders kunt besteden. Het is erger om geen buffertijd te hebben en die wel nodig te hebben, want in dat geval moet je op de een of andere manier alle benodigde tests in een kortere tijd uitvoeren. Dit kan ertoe leiden dat sommige testgevallen niet worden uitgevoerd, wat er op zijn beurt toe kan leiden dat bepaalde bugs pas direct in productie aan het licht komen.
Reikwijdte
Een ander belangrijk aspect van de preproductierelease is vanuit mijn perspectief het hebben van een speciale coördinator voor releasebeheer. Voor mij betekent dit iemand die voor bepaalde aspecten zorgt. Het eerste daarvan is: de reikwijdte van de release controleren. Voordat een release wordt getest, moet de tester weten wat er getest moet worden. Dit komt neer op de releasereikwijdte.
Productmedewerkers, oftewel de PO's of BA's, verwachten dat bepaalde functies in de release terechtkomen. Dit wordt afgesproken wanneer de ontwikkeling begint. De code die in de release terechtkomt, dekt echter niet altijd precies de reikwijdte die door het productteam wordt verwacht. Soms vergeten mensen code naar de branch te pushen waarvan de releasebuild wordt gemaakt. Of erger nog: ze pushen code naar deze branch die daar niet naartoe zou moeten worden gepusht. Dit kan betrekking hebben op functies die nog niet compleet zijn en waarvoor QA nog geen goedkeuring heeft gegeven, of op functies die geen deel uitmaken van de huidige reikwijdte.
Om ervoor te zorgen dat de reikwijdte wordt bereikt, moet de releasecoördinator de verwachte reikwijdte vergelijken met de daadwerkelijke reikwijdte. Hiervoor moet de verwachte reikwijdte afkomstig zijn van de productmedewerkers en duidelijk worden vastgelegd in een soort document (en misschien in je kwaliteitsborgingsplan). Je hebt bijvoorbeeld mogelijk planningsdocumenten waarin de projectmijlpalen en de inhoud van elke mijlpaal worden weergegeven.
Voor de daadwerkelijke reikwijdte moet er een wijzigingslogboek worden geëxtraheerd uit het VCS (versiebeheersysteem, bijvoorbeeld Git) dat het project gebruikt. Het wijzigingslogboek bevat alle commits die tijdens de ontwikkelingsfase zijn gemaakt naar de branch die de releasebuild zal genereren. Als je hopelijk op een georganiseerde manier werkt, bevat elke commit een beschrijving die verwijst naar een Jira-item waarop de code betrekking heeft. Zo kun je zien welke Jira-items bijbehorende code hebben die in de releasebuild terechtkomt, en welke van deze items niet in deze build hadden mogen worden opgenomen. Als je natuurlijk vaststelt dat deze commits betrekking hebben op noodzakelijke bugfixes, is dat prima. Wat je niet wilt, is dat deze commits staan voor onafgemaakt werk aan functies of werk dat betrekking heeft op functies die niet met de huidige release naar productie zouden mogen gaan.
Naarmate je je verdiept in geavanceerde technieken voor releasebeheer, zul je merken dat het integreren van je processen met testbeheeroplossingen die voor Jira zijn ontworpen een meer samenhangende en efficiënte workflow kan bieden
Wanneer er een verschil wordt gevonden tussen de verwachte en daadwerkelijke reikwijdte, moet de coördinator voor releasebeheer overleggen met het productteam en de managers van het ontwikkelingsteam om vast te stellen wat de beste aanpak is. Als de commits waarvan is vastgesteld dat ze geen deel uitmaken van de reikwijdte onafgemaakt werk aan functies vertegenwoordigen, kun je ze het beste verwijderen. Dit komt doordat je je al in de preproductiereleasefase bevindt en je niet het risico wilt lopen dat de resterende code gehaast wordt geschreven en getest, alleen maar om deze alsnog in de release te krijgen. Dat is riskant, omdat deze haast ertoe kan leiden dat testgevallen worden vergeten en niet worden uitgevoerd, en dat kritieke bugs in productie terechtkomen. In dit geval kun je het resterende werk aan deze functies het beste goed laten uitvoeren voor een toekomstige release.
Het testen
Zodra de reikwijdte duidelijk is, moet de testfase beginnen. Tijdens de preproductietestfase moet je de volledige functie die je uitbrengt opnieuw valideren. Je moet je voorstellen dat dit de eerste keer is dat je ernaar kijkt en elk scenario testen dat je tijdens de ontwikkelingsfase hebt getest. Voer de geautomatiseerde tests uit die je al hebt geschreven, maar dan in de preproductieomgeving, en vergeet de niet-geautomatiseerde scenario's niet. Voer een volledige regressietest uit op deze functie, simpelweg omdat er in deze fase van het releasebeheer en in de preproductieomgeving waarschijnlijk andere teams zijn die in dezelfde periode als jij een release moeten uitvoeren. Dit is in feite de eerste keer dat alle afhankelijkheden samenkomen met productieklare code in dezelfde omgeving. En dit is in theorie de configuratie die vanaf de release in productie zal draaien.
Tenzij er tijdens het testen problemen aan het licht komen en oplossingen nodig zijn. Als dat gebeurt, moet je bepalen wat je opnieuw moet testen. Ongeacht of de oplossing in jouw code zit of in de code van een externe afhankelijkheid: als de wijzigingen op welke manier dan ook invloed hebben op jouw functie, moet je een nieuwe testronde overwegen. Zorg ervoor dat je ten minste de kritieke functionaliteit van de functie opnieuw test.
Dit kan saai lijken, vooral als er tijdens deze fase veel oplossingen plaatsvinden. Je kunt de impact die de oplossingen op verschillende onderdelen van je functie kunnen hebben echter niet nauwkeurig voorspellen.
Kleine wijzigingen kunnen enorme neveneffecten veroorzaken. Het is daarom beter om je te vervelen maar er vertrouwen in te hebben dat de kritieke functionaliteit nog steeds goed werkt, dan er spijt van te krijgen dat je niet genoeg hebt getest.
En natuurlijk: als een bug die tijdens deze testfase wordt gevonden slechts een kleine bug is, probeer die dan niet tijdens deze fase op te lossen. Nogmaals, je wilt geen implementatie of tests overhaasten voor een verder perfect werkende functie, zodat je niet het risico loopt deze defect te maken.
Tijdens de uitrol zijn communicatie en testen essentieel.
Zodra de functie in de preproductieomgeving is goedgekeurd, is deze klaar om naar de productieomgeving te gaan.
Communicatie
Bij een uitrol naar productie moet de coördinator van het releasebeheer een aantal taken uitvoeren. Allereerst moeten de datum en het tijdstip van de uitrol ruim van tevoren correct worden vastgesteld en aan alle betrokken partijen worden meegedeeld. Ik merk dat het erg behulpzaam is voor het releasebeheer om de datum en het tijdstip van de uitrol als vergadering in de agenda's van de deelnemers vast te leggen, zodat de deelnemers hun dag kunnen organiseren. Dit is een taak die de coördinator kan uitvoeren.
Op de dag van de uitrol moet de coördinator iedereen die bij de planning van de uitrol betrokken is, eraan herinneren. Idealiter vindt de communicatie plaats via een kanaal dat iedereen gebruikt, bijvoorbeeld Slack. Een speciaal Slack-kanaal waarin alle belangrijke aspecten worden gecommuniceerd, zorgt ervoor dat iedereen die betrokken is hetzelfde beeld heeft van welke stap van de uitrol wanneer is uitgevoerd, wat de reikwijdte is, welke problemen aan het licht zijn gekomen en wie kan helpen bij deze problemen. Dankzij dergelijke communicatie zal iemand die bepaalde aspecten van de uitrol moet kennen deze informatie zien, in tegenstelling tot mondelinge communicatie (waarbij deze persoon afwezig kan zijn zonder dat degene die de informatie verstrekt, merkt dat deze persoon ontbreekt).
De coördinator van het releasebeheer moet de mijlpalen van de uitrol op dit kanaal bijhouden en aankondigen, bijvoorbeeld wanneer de uitrol begint en wanneer deze is goedgekeurd. Ook moet elke partij die bij de uitrol betrokken is via dit kanaal communiceren dat de toegewezen stappen worden uitgevoerd, zodat alle anderen op de hoogte zijn van de status en voortgang van de uitrol. Als een partij die op enig moment tijdens de uitrol nodig is niet beschikbaar is, moet de coördinator van de uitrol contact opnemen met de juiste personen om ervoor te zorgen dat alles soepel verloopt.
Het testen
Tijdens de uitrol naar productie moet de nieuwe functie opnieuw volledig worden getest. Dit komt doordat de functie weliswaar in andere testomgevingen is goedgekeurd, maar die omgevingen qua configuratie en resources niet voor 100% identiek zijn aan de productieomgeving.
Om onverwacht slecht gedrag van de uitgerolde functie te voorkomen, is het belangrijk om alle beschikbare geautomatiseerde tests uit te voeren, samen met de niet-geautomatiseerde onderdelen waarvoor je testgevallen hebt geschreven. Geef nooit goedkeuring voor productie zonder een functie te hebben getest.
Ervan uitgaan dat de functie in productie werkt, betekent niet dat dit ook daadwerkelijk zo is.
Zorg ervoor dat dit inderdaad zo is en test de functie.
Na de uitrol
De uitrol is dus voltooid. Maar ervoor zorgen dat de functie goed werkt, omvat meer dan deze alleen tijdens de uitrolfase testen.
Zodra je daarmee klaar bent, moet je ervoor zorgen dat je geautomatiseerde tests voor productie in de CI worden uitgevoerd. Hiermee wordt ongewenst gedrag opgespoord dat wordt veroorzaakt door externe wijzigingen waarvan je niet op de hoogte bent.
Houd de prestaties van de functie voortdurend in de gaten om ervoor te zorgen dat belasting van de productieomgeving en klantgebruik geen prestatievermindering veroorzaken. Zorg er ook voor dat je aandacht besteedt aan probleemmeldingen van je klanten. Deze kunnen aangeven welke onderdelen niet goed werken, zodat je indien nodig snel een toekomstige update kunt plannen.
En als de uitrol niet naar verwachting is verlopen, moet je zorgen voor een evaluatievergadering na de uitrol. Daarin kun je alle problemen bespreken die zich binnen het beheerproces van de uitrol hebben voorgedaan en actiepunten toewijzen aan de relevante personen, zodat toekomstige uitrollen soepel en succesvol verlopen.
