Onder softwareontwikkelaars is 'continuous delivery' een serieuze trend. Continuous delivery is een ontwikkelmethode die zowel invloed heeft op technische als organisatorische processen. Waar ik me op wil focussen is de invloed van het onderliggende platform op een Otap-omgeving (Ontwikkeling, test, acceptatie, productie en de manier waarop developers daarmee omgaan.)
Een ontwikkelmethode dus, die zich zowel op technisch als organisatorisch gebied laat gelden. Denk aan werkwijzen als Agile, Scrum en Kanban, maar ook aan vergaande softwarematige automatisering binnen het ontwikkelproces. Eerder legde Dennis Doomen op deze site al uitstekend uit hoe continuous delivery in zijn werk gaat, dus ik zal er zelf niet te diep op ingaan.
De doorsnee developer of tester heeft een hekel aan toeval en wil elke vorm van onvoorspelbaarheid uitsluiten, als dat enigszins mogelijk is. Dat komt tot uiting in continuous delivery: alle processen vanaf het ontwikkelen tot en met het in productie nemen van een applicatie worden waar mogelijk geautomatiseerd. Het doel is om het risico op (menselijke) fouten te verminderen en het ontwikkelproces te versnellen. De samenwerkingsvorm speelt leentjebuur bij Scrum en Agile. Een ontwikkelteam realiseert één feature of onderdeel in een korte sprint en gaat niet door naar het volgende onderdeel voordat deze feature is afgerond en in een acceptatie- of productieomgeving staat.
In de afgelopen jaren heb ik veel samengewerkt met developers en testers. En als ik dan op een rij zet waar continuous delivery om draait, verbaast het me sterk dat veel van deze experts weinig zicht hebben op de invloed van het onderliggende it-platform op hun ontwikkel- en testomgeving. Nog verbazender: ze accepteren de it-omgeving als onvoorspelbare factor!
Otap
De factor it, als voorbeeld een Otap-ontwikkelstraat met afzonderlijke ontwikkel-, test-, acceptatie- en productie-omgevingen en uitwijklocatie, mag geen onvoorspelbare factor zijn. Hoge en vooral ook constante performance is bepalend voor de uitkomsten van tests en de kwaliteit van patches, onderdelen of nieuwe features die worden uitgerold.
Maar goed, hoe kan een it-omgeving dan van onvoorspelbare factor tot een zekerheid worden omgevormd? Hoe krijg je inzicht in het niveau en de stabiliteit van performance en connectiviteit? Hoe zorg je er voor dat een omgeving voor acceptatie dezelfde omstandigheden als de productie-omgeving biedt? Allerlei eigenschappen spelen een rol: responstijd van geheugen en storage, belasting en performance van de infrastructuur, cpu ready time en ga zo maar door. Het is erg complex om alle onderdelen op elkaar aan te laten sluiten en een constant presterende omgeving neer te zetten. Dat mag echter geen reden zijn om de invloed van de genoemde hardware-eigenschappen dan maar te negeren.
De rol van de hoster
Kort samengevat: developers hebben een sterke focus op het perfectioneren van de applicatie, maar gaan er van uit dat ze weinig of geen invloed hebben op de it-omgeving en connectiviteit. En juist daar kan een hoster het verschil maken door een stabiel, hoog beschikbaar en onafhankelijk platform te bieden en deze continu te monitoren. Als het it-platform volledig beheerst wordt, is het geen variabele tijdens testprocedures, maar een constante. Een specialisme waar testers en developers zich geen zorgen over hoeven te maken.
Misschien dat de schrijver eens een dagje mee kan lopen met de ontwikkelaars om zelf te ervaren hoe het er echt aan toe gaat. Het is in de praktijk nl. erg lastig om een zeer complexe omgeving waarbij meerdere processen die van elkaar afhankelijk zijn in het gareel te houden.
De hardware is zeker van invloed en dat heeft niet te maken dat deze onbetrouwbaar zou zijn maar eerder dat de belasting hiervan niet exact te voorspellen is. In navenant elk stukje hardware zijn legio processen die parallel lopen maar allemaal verdeeld worden over een aantal seriële processoren inclusief de zaken om de werking van de hardware zelf aan te sturen. Dat is inherent aan de gekozen architectuur en daar zal dus rekening mee gehouden dienen te worden.
Ik kan hier een heel betoog over schrijven, maar in het kort komt het er op neer dat men vaak wel iets aan versiebeheer doet, maar niet aan configuration management.
bla bla bla, de auteur heeft hosting te koop.
Beste Johan, bedankt voor het lezen van mijn blog en het geven van je reactie. Met grote interesse volg ik de ontwikkelingen op het gebied van continuous delivery. Ik ben daarom erg benieuwd naar je visie op dit gebied! Ben je geïnteresseerd om persoonlijk van gedachten te wisselen?