Inmiddels zijn we allemaal it’er. Jij ook. Immers, we vertegenwoordigen allemaal een organisatie die zo snel mogelijk en tegen zo hoog mogelijke kwaliteit it in productie wil zetten. Door snel businesswaarde toe te voegen, maken we onze organisaties flexibel, adaptief en competitief.
Je hebt zoals vele anderen ervaren dat bij het realiseren van die businesswaarde coderen en testen parallel lopen. Het een kan niet meer zonder het ander. Deze activiteiten werden vroeger nog als zelfstandige, afgebakende taken uitgevoerd door ‘ontwikkelaars’ en ’testers’. Inmiddels zijn het taken van een team geworden en veelal samen uitgevoerd. We zijn allemaal dev-engineer geworden, toch?
Nu het niet meer uitmaakt wíe de verantwoordelijkheid heeft voor een activiteit in een team (áls het maar gebeurt) is het ook tijd om je te realiseren dat het ook niet hoeft uit te maken wáár de activiteit wordt uitgevoerd (áls het maar gebeurt). We hebben het nu niet over distributed agile teams of thuiswerken, we breken hier een lans voor het doorbreken van een paradigma: stop met denken in otap (ontwikkeling, test, acceptatie en productie)-omgevingen. Waarom?
Waste
Je wilt met it zo snel mogelijk businesswaarde toevoegen. En dan ook nog tegen hoge kwaliteit. Die snelheid kun je alleen bereiken als je herkent waar in het proces ‘waste’ ontstaat en deze elimineert. Werken in otap-omgevingen betekent dat je in jouw voortbrengingsproces op weg naar productie enkele stappen herhaalt: code deploy naar een nieuwe omgeving, controleren van de juiste versies, testdata klaarzetten, connectiviteit juist zetten, test scripts starten, logging interpreteren en/of andere al dan niet handmatige acties. Bij elke omgeving opnieuw. Je creëert waste. Je vertraagt de boel!
De huidige technologie biedt ons een alternatief waarin het niet meer nodig is om otap-omgevingen neer te zetten, in te richten, te koppelen aan activiteiten en te beheren. Door dit alternatief slim in te zetten, win je flink aan snelheid en krijg je zelfs eerder feedback op kwaliteit.
Create, deploy, destroy
Je kunt gaan werken met containers. Containers zijn tijdelijke omgevingen waarmee je in staat bent om delen van applicaties te verplaatsen door allerlei fases zonder die software steeds weer opnieuw te installeren. In plaats van dat de verschillende procesfases een nieuwe omgeving vereisen, laat je de container met de software door de fases heengaan. Je bent hierdoor in staat om continu businesswaarde naar productie te brengen.
En daarmee is het mogelijk om ontwikkelde code in snelle feedback iteraties te valideren op alle aspecten die nodig zijn om de businesswaarde te garanderen; zonder dat deze code over verschillende omgevingen gedistribueerd hoeft te worden! Je kunt bijvoorbeeld een container met de aangepaste software opspinnen, daar de api-test op uitvoeren en als deze succesvol is uitgevoerd, de container te koppelen aan een klein stukje van de keten (waarbij je de oude deactiveert en verwijdert).
Verschil met otap
Wat is het verschil dan met een otap-omgeving? Het verschil zit hem erin dat je eigenlijk nog maar twee omgevingen hebt: een productieomgeving en een niet-productieomgeving. In de productieomgeving heb je de software draaien waarvan de kwaliteit is bewezen en waarmee je businesswaarde genereert. In de niet-productieomgeving heb je een hele set aan containers, cloud-oplossingen of andere opties die ‘onsamenhangend’ geplaatst zijn. De gehele ‘ota’ is hiermee dynamisch geworden. Op elk moment kan er een koppeling worden omgehangen waarmee een stukje van de nieuwe software ineens meedraait in een productieketen. Deze aanpak heeft tot doel zo snel mogelijk de kwaliteit te bewijzen. Daarmee wordt extra businesswaarde zo snel mogelijk gerealiseerd. Door af te stappen van vaste omgevingen en te gaan naar dynamische ketens zorg je ervoor dat specifieke activiteiten op de juiste momenten uitgevoerd kunnen worden.
Voorbeeld
Stel dat het gewenst is om een uitspraak te hebben over de kwaliteit van een deel van de beveiliging van een gewijzigde applicatie. In otap-omgevingen zie je vaak dat het gewijzigde stuk software eerst de o-, de t- en a-omgeving moet hebben doorlopen voordat de beveiliging wordt getest. Er vinden vier deploys plaats. Dat is waste.
Als je werkt met containers dan zet je de nieuwe code eenmalig neer. De configuratie bepaalt of deze code in een bepaalde keten hoort (of losstaand is). Je kunt de securitytest laten uitvoeren en als de software voldoet dan kan dit stuk software direct in de productieketen meedraaien. Eenmalig klaarzetten in plaats van viermaal.
Stop dus met het verplicht doorzetten van nieuwe software door een gehele otap-straat als daar geen reden toe is. Hiervoor krijg je veel automatisering, kwaliteit en vooral veel meer tijd terug. Deze tijd kan je dan besteden aan het creëren van nieuwe businesswaarde. Het maakt je sneller en wendbaarder. O ja, en als jij het niet doet, jouw concurrent doet het al.
Jelle Schutte, cto, en Joost Jongman, technical solution architect, bij Valori
