Applicaties in productie brengen blijkt in de praktijk nog steeds een moeizaam en risicovol proces. Waar we tijdens de ontwikkelfase beschikken over een soepel draaiende toepassing, wordt het spannend zodra we de staging-fase ingaan. Dan… kan er alsnog van alles mis gaan.
Vanwege mogelijke continuïteitskwesties kiezen veel organisaties ervoor om een reeks policies toe te passen op de uitrol van applicatie(updates) om zo de risico’s zoveel mogelijk in te perken. Risico’s die worden vergroot door de mate van handwerk en het niet (voldoende) testen van applicaties tijdens het staging-proces. Hierin wordt onder meer bepaald welke voorbereidingen er nodig zijn, zoals de scripts die geschreven moeten worden en inzicht hebben in de afhankelijkheden. Met andere woorden: welke applicatie dient als bron en welke applicaties worden door de te stagen applicatie ‘gevoed’.
Het beleid voor het in productie brengen van applicaties strekt zich verder uit tot een aantal policies, waaronder:
- Er is een vast periodiek moment waarop toepassingen en updates uitgerold mogen worden. Vaak is dat eens per maand.
- Tijdens ‘runs’ mogen applicaties niet in gebruik zijn.
- Er worden nooit updates van afhankelijke applicaties gelijktijdig ‘live’ gebracht.
Al deze voorwaarden zijn gerechtvaardigd vanuit een continuïteitsoogpunt. Omdat er maar een keer per maand ‘gedeployed’ wordt, is er een absolute beperking in tijd. Daarom zal er bepaald moeten worden welke applicaties prioriteit krijgen en zal er per applicatie een maximale (test)tijd beschikbaar gesteld moeten worden waarbinnen groen licht gegeven wordt. Wanneer dit go/no go-moment niet gehaald wordt, verschuift de uitrol naar de volgende deployment window. Die zal dan onder invloed van interne behoeften, nieuwe wetgeving of veranderde afspraken binnen een sector meer changes bevatten en dus meer tijd in beslag nemen bij een volgend deploy-moment. Gevolg is dat een door de ‘business’ aangevraagde verandering vaak zeer lang op zich laat wachten.
De hierboven beschreven situatie is vooral in het belang van de continuïteit en dient niet de bedrijfs- en afdelingsdoelstellingen. Ze zet daarom meer dan eens de verhoudingen tussen it en de business op scherp. In mijn ogen onnodig, want er zijn alternatieven waarin de zakelijke behoeften gediend kunnen worden tegen een minimale of zonder verstoring van het bedrijfsproces. Een logische keuze is om de deploy-frequentie op te voeren met minder changes, het testwerk te reduceren en te bepalen waar onderdelen geautomatiseerd kunnen worden.
Door deze manier van inrichten ontstaat er een proces dat zowel voor de business als voor it in een logische flow van activiteiten resulteert. Niet meer die periodieke lastige onderbrekingen, maar een constante updatestroom die de wijzigingsbehoefte van de business steeds bijhoudt. Voorwaarde is een vergaande samenwerking tussen de softwareontwikkelaars en de operationele it-afdeling, gezien hun onderlinge afhankelijkheid.
DevOps speelt hierop in. Deze term, een samentrekking tussen Development en Operations, dook enige jaren geleden voor het eerst op. DevOps belooft om voor deployment te doen wat agile voor softwareontwikkeling gedaan heeft. Sinds 2009 worden de DevOp Days georganiseerd om softwareontwikkeling en de operationele it-afdeling te synchroniseren met als doel om applicaties soepel in productie te brengen. Hierbij worden voorbeelden aangehaald van grote bedrijven zoals Facebook en Google en geanalyseerd hoe zij hun ontwikkel- en uitrolprocessen hebben ingericht.
Deze sessies in combinatie met een aantal vooraanstaande denkers moeten leiden tot een concrete invulling voor het gedachtegoed. Een voorbeeld hiervan is Gene Kim, oprichter van Tripwire en initiator van IT Revolution. Hij is erg actief op dit vlak en werkt aan het DevOps Cookbook om DevOps verder te structureren en inzichtelijk te maken. Op kleinere schaal dragen ook wij ons steentje bij. Tijdens myNextStep op 14 februari in Breda zal ik de relatie tussen agile en DevOps onder de loep nemen en toelichten hoe het deployment-proces door middel van tooling ondersteund kan worden.
De hierboven beschreven situatie is vooral in het belang van de continuïteit en dient niet de bedrijfs- en afdelingsdoelstellingen
Met dit citaat gaat het hele verhaal mank in mijn ogen. Als de coninuïteit niet geborgd wordt, dan worden de bedrijfs- en afdelingsdoelstellingen wel degelijk geraakt.
Waar het, mijns inziens, steeds vaker misgaat is dat het ontbreekt aan systeemkennis. Als ik dit aanpas, wat wordt er dan nog meer geraakt. Wat zijn de afhankelijkheden, wat zijn de scenario’s waarin dit stukje code geraakt wordt.
Veel mensen kennen alleen maar hun eigen stukje code, hun eigen app, maar weten niet hoe dit past in het grote geheel van een systeem.
Mooi artikel, vooral de sprong naar het onderwerp DevOps en de combinatie met Agile is een verhelderend aspect. De laatste tijd veel mensen hierover gesproken, die vooral de sprong van Agile naar DevOps maar niet voor elkaar krijgen en denken dat DevOps een methode met standaard framewerk is.
Beste PaVaKe (helaas heb je je naam niet gegeven),
Je geeft precies aan waar ik graag op ons event een nadere toelichting over geef. Dit is beslist een gebied waar veel schade voor zowel continuïteit als het realiseren van de bedrijfsdoelstellingen kan ontstaan. In feite is het één een resultaat van het andere.
De tooling die ik wil bespreken behoed DevOps voor de altijd op de loer liggende risico’s om afhankelijkheden tussen nieuwe en bestaande applicaties en integraties over het hoofd te zien.
Door hierin tooling aan te bieden die de taak van stage-ing vereenvoudigd kan er ten eerste een significante tijdswinst als ook kwaliteitsverbetering behaald worden. Door IT teams hiermee te ondersteunen / uit te rusten zijn organisaties in staat om in zeer korte iteraties nieuwe functionaliteit beschikbaar maken voor de business. (typisch in 2 weken durende iteraties).
Ik zou jullie (ook Mickel) graag ontmoeten op ons event en daar verder van gedachte wisselen. Dank voor jullie reactie.
Ruud Hochstenbach
OutSystems