Weg uit de deployment-hel

Computable Expert

ing. Ruud Hochstenbach

Business Development Manager

Expert van Computable voor de topics: Softwarebeheer, Management en Development

Meer

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.