Totale verantwoordelijkheid
Tijdens een vorige blog van deze reeks is er besproken wat er allemaal nodig is om losse ideeën, verbeteringen of noden te transformeren naar concrete features. Dat zijn omschrijvingen van kleine stukjes functionaliteit van een digitale oplossing, geschreven vanuit het perspectief van de eindgebruiker.
Vanaf dan breekt de echte deliver fase aan waar functionaliteiten gebouwd, getest en in de lucht gehouden worden. Hiervoor komt een multidisciplinair productteam in actie. Zij staan in voor hun ganse proces, van de implementatie van nieuwe features tot het opereren van alles wat er reeds in productie staat. Elk team is end-to-end verantwoordelijk voor z'n deliverables en dat tijdens de hele levensloop ervan.
Dit is de basis van de echte DevOps mindset: you build it, you run it. Dit bewustzijn leidt vaak tot impliciete kwaliteitsverbetering. Als je 's nachts of in het weekend instaat voor eventuele problemen, zal je ervoor zorgen dat het systeem zeer stabiel is en bouw je zoveel mogelijk ‘resiliance’ in de software in. Dit maakt ook dat deze teams per definitie stabiel en matuur dienen te zijn. Of je nu eerder de DevOps aanpak of de SRE aanpak verkiest, dat maakt voor ons verhaal niet zoveel verschil. Vandaar dat we in deze blog de algemene benaming ‘productteam’ hanteren.
Win efficiëntie en effectiviteit met transversale sturing
Naast ieders eigen verantwoordelijkheid, zijn er ook heel wat zaken die best transversaal opgezet worden. Niet ieder team moet zelf het warm water uitvinden. DevOps ondersteuningssystemen zoals Atlassian en Azure DevOps bevatten essentiële bouwstenen om een goede werking te garanderen. Naast source control en pipelines om CI/CD (Continuous Integration en Continuous Deployment) systemen op te zetten, zijn er ook geïntegreerde samenwerkingstools om een agile werking te faciliteren. De tooling zorgt, samen met de processen, voor continue feedback loops om kennis en ervaringen te laten circuleren tijdens het proces. Zo hou je de vinger aan de pols (‘zijn we het ding juist aan het bouwen’) en optimaliseer je de werking en kennis van een team.
Dit soort processen en tools worden transversaal over de verschillende DevOps teams heen uitgerold en onderhouden, zodat ze eenvoudig gebruikt kunnen worden en ze een team echt faciliteren. Het is steeds een balans die gevonden moet worden qua invulling van de eigenlijke processen en pipelines. Hoeveel kan er transversaal gestuurd worden en wat is de verantwoordelijkheid van elk team op zich? Zoals gezegd nemen teams een end-to-end verantwoordelijkheid op en ligt het laatste woord ook bij hen. Tegelijk is een software delivery proces zeer gestroomlijnd en liggen de stappen die genomen moeten worden vrij vast. Meer maturiteit op het vlak van softwareontwikkeling gaat vaak hand in hand met meer transversale processen en tools.
Testen, testen, testen
Onderstaand schema geeft een high level beeld van de verschillende fasen en stappen die we zien in een agile software delivery proces. Bij een automatische pipeline zijn deze stappen volledig geautomatiseerd.
We bevinden ons in de fase na het commitmentpunt waarop de organisatie heeft beslist om echt van start te gaan met de concrete ontwikkeling van een functionaliteit. De user story die werd geschreven in menselijke taal wordt omgezet in lijnen code.
Als onderdeel van Continuous Delivery zorgt het bouwproces (CI) dat er van de code een binair artifact(1) gemaakt wordt. Dit is ook het ideale moment om de code te onderwerpen aan verschillende testen zodat we meteen een beeld krijgen van de kwaliteit ervan. Denk bijvoorbeeld aan automatische unit tests en static code analysis tools zoals SonarQube om de code grondig te valideren. Typisch wordt er dan een score gegeven op basis van het aantal bugs, kwetsbaarheden, code smells, het slaagpercentage van de unit tests, alsook hoeveel percent van de functionaliteit de unittesten afdekken (code coverage). Dit is zeer belangrijke feedback waar onmiddellijk mee aan de slag moet worden gegaan. Een build die niet aan de minimale eisen voldoet kan beter worden tegengehouden om de kwaliteit te garanderen. Een CI-systeem helpt hierbij aangezien het een automatisch proces start wanneer een ontwikkelaar z’n code ‘commit’ in de source-repository. Het systeem zet de build in gang en laat de automatische testen lopen.
Voor de deployment van deze artifacten naar de verschillende systemen zijn er ook steeds automatische stappen te doorlopen, afhankelijk van de gebruikte technologie. Cloud native systemen zoals Kubernetes zijn fundamenteel anders. In de toekomst zal de gebruikte soort pipeline ook verder evolueren. Er wordt tegenwoordig al gewerkt aan event gedreven systemen (Keptn (keptn.sh) hanteert deze bijvoorbeeld) die ideaal werken in een Kubernetes-omgeving met meer dan honderden micro-services. Automatische testen tijdens de verschillende fases van de traditionele deploy pipeline moeten ook zorgen voor impliciete en continue kwaliteitsverbetering.
Expliciete testen op performance, aan de hand van load/stress testing, maken ook integraal onderdeel uit van de automatische pipeline. Omgevingen worden hier ook op gemonitord. Dit gebeurt op systeemniveau maar vooral op het niveau van applicaties (observability) en zelfs gebruikersniveau (real user monitoring). Door een systeem zoals Dynatrace in te zetten op de lagere omgevingen (TEST, INT, ACC, …) kunnen de inzichten die gepaard gaan met allerhande testen van binnenuit bekeken worden. Dit bespaart heel wat kostbare tijd tijdens het troubleshooten van bugs en zorgt ook impliciet voor kwaliteitsverbetering.
Daarenboven zijn en blijven manuele testen ook nog steeds enorm belangrijk. In een multidisciplinair team zetelen dus idealiter ook mensen met testing skills. Tegelijk is het voor sommige organisaties zeer interessant om test management en coaching transversaal op te zetten. Security is ook zo’n topic, het moet in zeker mate ingebouwd worden in een team maar het kan ook perfect transversaal gefaciliteerd worden.
Het uiteindelijke doel van al die testen is natuurlijk een technisch werkend geheel, maar ook de beoogde waarde en praktisch nut mag niet uit het oog verloren worden. Hebben we iets gebouwd dat overeenkomt met de initiële verwachtingen? Zijn de user stories terug te vinden in het resultaat? Die feedback loops zijn erg belangrijk én kenmerkend voor een agile manier van waardecreatie.
(1) binair artifact: van code naar machinetaal, zodat het kan uitgevoerd worden door een machine
Dit artikel maakt deel uit van een blogreeks rond alle belangrijke onderdelen van een agile ontwikkelproces. Lees ook zeker deze: