IT

Continuous Delivery: vereenvoudig het delivery process

Continuous Delivery is een onderdeel van de Agile-aanpak. Pas je Continuous Delivery toe als IT-organisatie, dan moet je er rekening mee houden dat het echt een denkwijze is die je je eigen moet maken. Het team produceert in korte sprints en zorgt ervoor dat het product op elk moment live kan gaan. 

Het doel van Continuous Delivery is om de tijd tussen het hebben van een idee, en dat idee bij de gebruikers krijgen, aanzienlijk te verminderen. “The Principle of the 3 ways” helpt daarbij. Dat zijn richtlijnen die helpen bij het verbeteren van het software delivery proces. 

Hoewel Continuous Delivery zeker niet eenvoudig toe te passen is, en zeker in het begin best veel moeite en tijd kost, staat Thierry de Pauw toch achter deze aanpak. Tijdens onze Tech Talk op 23 februari vertelde hij daar met veel enthousiasme meer over

1. Van links naar rechts

In dit geval ligt de nadruk op het maximaliseren van de doeltreffendheid van het software delivery process. Hoe ga je te werk?

Streef naar een herhaalbaar en betrouwbaar software delivery process

Dat houdt in dat je alles wat je kan automatiseren, ook daadwerkelijk automatiseert. Denk aan de installatie en configuratie van applicaties of de configuratie van firewalls. Bovendien moet alles wat je nodig hebt om jouw toepassing te bouwen, testen, installeren en vrijgeven onder versiecontrole bewaard worden.

Spoor samenwerking aan binnen 1 productteam

Om de doorvoercapaciteit te verbeteren, is het belangrijk om samenwerking aan te moedigen. Zowel product managers als testers, security engineers, operation engineers en software engineers moeten naar hetzelfde doel werken: waarde creëren voor de klanten, zodat de organisatie winst maakt.

En laat ons eerlijk zijn: dat is moeilijk als iedereen in zijn eigen departement zit. Het is daarom het beste om iedereen samen te brengen in 1 gemachtigd productteam. Zij hebben dan de volledige verantwoordelijkheid over de toepassing. Uiteindelijk zal deze aanpak leiden tot een betere kwaliteit, wat de klant dan weer ten goede komt!

Werk aan 1 feature per keer

Je opteert best voor een enkelvoudige flow: het hele team werkt aan 1 feature per keer. Is het feature klaar? Release het dan in plaats van te wachten tot aan het einde van de sprint. De WIP (Work in Progress) verminderen is daarbij belangrijk. Zo zal iedereen zich automatisch gaan richten op 1 feature. 

Bij Continuous Delivery creëer je dus geen gigantische ladingen features, want dat verhoogt het WIP. En meer WIP wil zeggen dat je meer voorraad gaat creëren: code die als het ware rondslingert en niet in productie gaat, waardoor het geen waarde toevoegt. Hoe meer voorraad er is, hoe meer geld blijft vastzitten in het systeem. En dat is geld dat de organisatie niet kan investeren. Conclusie? Code die je niet gebruikt, gooi je weg.

Als je team maar aan 1 feature per keer werkt, levert dat nog een aantal andere voordelen op:

  • Je oefent vaker het release proces.
  • Het is makkelijker om te achterhalen wat er misging.
  • Het is makkelijker om kleine, recente aanpassingen terug te draaien, dan aanpassingen die bv. 6 maanden geleden zijn uitgevoerd.

Toepassing is altijd klaar om live te gaan

Dit is een van de basisprincipes van Continuous Delivery. Moet je het product om bepaalde redenen onverwachts lanceren? Dan moet je team daar effectief toe in staat zijn. “Klaar zijn” om live te gaan, wil niet zeggen dat je de toepassing ook effectief moet releasen. Het levert wel veel flexibiliteit op en zorgt ervoor dat software die nog niet helemaal klaar is, toch live kan gaan.

Maar hoe zorg je ervoor dat je toepassing altijd klaar is om live te gaan? Door trunk based development toe te passen! Alle developers dragen minstens 1 keer per dag bij aan 1 gedeelde branch, de “trunk”. Op die manier hoeven ze geen andere development branches te creëren en is er maar 1 main branch. Trunk based development zal het team ook aanmoedigen om stap voor stap te werken, wat ook een belangrijk principe is van Continuous Delivery.

    Zo pas je trunk based development toe:

    • Breek grote veranderingen op in kleine stapsgewijze veranderingen.
    • Als een nieuwe functionaliteit nog niet klaar is, maar je wil de toepassing toch vrijgeven, verstop dan de functionaliteit, zodat de gebruikers het gewoon niet zien.
    • Pas branch by abstraction toe. Het laat je toe om grootschalige aanpassingen aan de toepassing uit te voeren zonder de toepassing volledig te breken en ze toch regelmatig te kunnen releasen, terwijl de veranderingen nog aan de gang zijn.
    • Pas feature toggle toe. Op die manier kan je features aan- en uitzetten. Dat geeft bijkomende flexibiliteit. Hou er wel rekening mee dat het complexiteit toevoegt aan het proces.

    2. Van rechts naar links

    Wat houdt een Tech Talk in?

    Maandelijks bijleren over uiteenlopende IT-topics in een gezellig kader (denk: foodtruck!).

    In dit geval bouw je feedback in om ervoor te zorgen dat een probleem niet opnieuw voorvalt, en dat je problemen vroeg kan ontdekken. Dat laatste is belangrijk: hoe langer het duurt om een probleem te ontdekken, hoe langer het ook duurt om het op te lossen. Hoe ga je te werk?

    Als er iets faalt, stop dan de productielijn

    Zodra er iets fout gaat, stop je met wat je aan het doen bent en los je het probleem onmiddellijk op. Je giet het dus niet in een ticket! Doe je dat wel, dan krijg je een lange lijst met mankementen en heb je ook veel tijd nodig om die lijst te overlopen.

    Ga van bij het begin voor kwaliteit

    Kwaliteit bouw je van bij het begin in. Je “test” het er niet later pas bij. En die kwaliteit is niet enkel kwaliteit van de code. Het is ook business kwaliteit (voldoen de functionaliteiten voor gebruikers), operationele kwaliteit (werkt de toepassing, is ze schaalbaar en is ze voldoende beveiligd) en performantiekwaliteit.

    Dat impliceert ook dat testen geen fase is; het is deel van je development process. Het hele team is verantwoordelijk voor die kwaliteit. Daarom is het, zoals eerder al aangehaald, belangrijk om iedereen in 1 team samen te brengen. De kwalitiet van het product is immers de verantwoordelijkheid van iedereen, niet enkel van de testers.

    Om kwaliteit in te bouwen, neem je best Continuous Testing op met de Testpiramide.

    Unit tests

    Je begint met het opbouwen van een stevige basis unit testen. Dat zouden er duizenden moeten zijn, die bovendien verschrikkelijk snel uit te voeren zijn.

    Acceptatietesten

    Daarbovenop voorzie je geautomatiseerde acceptatietesten. Dat zouden er honderden moeten zijn. Die acceptatietesten zijn eigenlijk uitvoerbare acceptatiecriteria en fungeren als regressietesten. Elke User Story zou minstens een acceptatiecriteria moeten bevatten dat automatiseerbaar is.

    End-to-end testen

    Vervolgens pas je end-to-end testen toe. Dat zijn smoke testen die je uitvoert in de productie-omgeving om te checken dat alles correct is ingesteld (is de database aanwezig? Zijn derde partij diensten beschikbaar?). Als alles in orde is, kan je overgaan tot het releasen van de feature en kunnen de gebruikers ermee aan de slag.

    Manuele exploratietesten

    Eenmaal de unit testen en automatische acceptatietesten succesvol zijn, kan je starten met de  manuele exploratietesten. Zodra je toekomt aan die exploratietesten, zou je al een heel goed vertrouwen moeten hebben in de kwaliteit van de toepassing.

    Tijdens de manuele exploratietesten gaan testers op zoek naar alle ongekende problemen. Dat is wat we Testen noemen. Unit en acceptatietesten zijn eigenlijk checks: ze checken alles wat we weten. De manuele exploratietesten zorgen ervoor dat ongekende problemen vertaald worden in nog meer checks, zodat de eventuele problemen die aan het licht komen, niet meer opduiken in de toekomst.

    3. Een cultuur van continu verbeteren instellen

    Je delivery pipeline ontstaat niet van vandaag op morgen. Het is iets dat gradueel wordt opgebouwd, gebaseerd op de kennis die je opdoet en de problemen die je tegenkomt. 

    Je maakt best gebruik van regelmatige retrospectives waarbij iedereen aanwezig is die betrokken is bij het software delivery proces. Tijdens die retrospectives is het belangrijk om ook je software delivery process te bespreken en op zoek te gaan naar je bottlenecks. Waarom? Omdat het de bottlenecks zijn die je moet optimaliseren en ze bijgevolg de eerste kandidaten zullen zijn voor automatisatie.

    Het is niet eenvoudig om je software delivery process te bespreken tijdens retrospectives. Zowel technische teamleden (software engineers, operations engineers, security engineers) als minder technische teamleden (product managers, testers, UX designers) zijn aanwezig. 

    Hoe hou je het gesprek eenvoudig voor iedereen? Door gebruik te maken van een value stream map. Dat is een grafische weergave van je software delivery process. Het geeft grafisch alle stappen weer die nodig zijn om software van idee tot in de handen van de gebruikers te krijgen. 

    De value stream map geeft bovendien weer hoeveel tijd daadwerkelijk gewerkt wordt in elke stap en hoeveel tijd er gewacht wordt. In zijn simpelste vorm is een value stream map een Scrumbord. Gebruik je deze data, dan zal je eenvoudig je bottleneck kunnen opzoeken.

    Herhaling en oefening zorgen ervoor dat je het proces beheerst. Durf daarbij de pijnlijke punten naar voren brengen: is testen het zwakke punt? Doe het dan vaker. Is je software vrijgeven pijnlijk? Zet als doel voorop om het dagelijks te doen en werk ernaartoe.

    Wat onthoud je?

    Het is mogelijk om de doorvoercapaciteit op te voeren en toch een hogere kwaliteit op te leveren aan mindere kost. In het begin zal dit je heel wat moeite en geld kosten, omdat je een leercurve doorloopt. Maar daarna merk je zeker en vast de voordelen ervan.

    Continuous Delivery is zeker niet makkelijk en goedkoop, maar het levert je wel veel flexibiliteit op. Een product release zal dan niet veel meer voorstellen: het zal iets worden wat haast dagelijks gebeurt en niet meer opvalt.

    Over Thierry de Pauw

    Thierry is een Lean & XP Software Engineer met een DevOps-mentaliteit en meer dan 15 jaar ervaring. Hij is bovendien ook nog Continuous Delivery Consultant en Agile Technical Coach. 

    Hij houdt ervan om teams te helpen om betekenisvolle software te creëren. Hij heeft daarbij een scherp oog voor de kwaliteit van de code en het software delivery process, van customer interaction tot continuous delivery. 

    We moeten volgens Thierry niet op zoek gaan naar een evenwicht tussen kwaliteit en oplevering. Hij is ervan overtuigd dat betere kwaliteit een manier is om meer en beter op te leveren. Kwalitatieve code en het opleveren van functionaliteit gaan volgens hem hand in hand. 

    In zijn vrije tijd leest hij veel: eerst romans, nu vooral professionele literatuur. Is hij te moe? Dan leest hij stripverhalen. Zijn 2 kinderen vinden het geweldig als hij hen voorleest, zeker wanneer hij dat doet met speciale stemmetjes.

    Lees verder

    Mike and Thomas laughing
    Als collega’s vrienden worden: de bromance van Mike en Thomas
    #friendship #bromance
    Bedrading
    3 vragen aan Support Engineer Maarten
    #support #consultancy
    typewriter - blue
    Digital Savviness Academy: antwoord op digitale transformatie
    #IT #digitalsavvinessacademy