Experts maken geen deel uit van de redactie. Zij vertegenwoordigen dus niet het redactionele gedachtegoed van Computable.

Weg uit de deployment-hel

24-01-2013 13:11 | Door Ruud Hochstenbach | Lees meer artikelen over: Testing, Social media, Agile | Er zijn 3 reacties op dit artikel | Dit artikel heeft nog geen cijfer (te weinig beoordelingen) | Permalink
Computable Expert
Ruud Hochstenbach
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.

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.
Deel dit artikel via LinkedIn
Deel dit artikel via Facebook
Deel dit artikel via Twitter

46 vacatures
iOS Ontwikkelaar

Ordina , Nieuwegein

Microsoft Dynamics NAV Developer

MySolution , Houten

DBA / Developer

de Persgroep Nederland , Amsterdam

TIBCO SOA Software Engineer

Ordina , Nieuwegein

Software Designer die trots is op wat hij al kan met Java of C#

Technolution , Gouda

Top 10 reagerende bezoekers
      Aantal
reacties
Gemiddelde
waardering
Klik voor meer info 1 1992 6.86
Klik voor meer info 2 1502 6.67
Klik voor meer info 3 1142 6.67
Klik voor meer info 4 1218 6.63
Klik voor meer info 5 879 6.58
Klik voor meer info 6 586 6.30
Klik voor meer info 7 416 6.29
Klik voor meer info 8 1083 6.07
Klik voor meer info 9 701 6.05
Klik voor meer info 10 461 6.04