Ontwikkelstraat, waar moet je rekening mee houden?

Waar moet je rekening mee houden als je een DTAP ontwerpt, bouwt of gaat migreren? Deze serie artikelen is/wordt geschreven voor iedere IT ’er die te maken krijgt met een ontwikkelstraat. Een ontwikkelstraat (of DTAP/OTAP: Ontwikkel – Test -Acceptatie – Productie omgevingen) wordt gebruikt in iedere professionele IT-omgeving.

Momenteel ben ik dit artikel aan het herschrijven om naast de traditionele change-run ook DevOps mee te nemen. 

In de afgelopen 10 jaar heeft Reforge intensief te maken gehad met ontwikkelstraten voor applicaties binnen grote organisaties. Je leest of hoort alleen weinig over de infra aspecten ervan. In de praktijk wordt er door ontwikkelaars, business IT-consultants en hun project bazen met enig dedain over gesproken. ‘Zo moeilijk kan dat toch niet zijn, zo’n servertje’, ‘jullie infra-jongens moeten niet zo moeilijk doen’ en ‘dan gaan we toch zeker naar een externe Cloud leverancier’. Agile werken en Scrum maken het er niet altijd beter op. Platformen draaien nu eenmaal op hardware en hardware heeft een lever- en installatietijd. Je kunt niet even een platform bij elkaar ‘scrummen’ want je IT-leverancier hanteert regelmatig een contractueel overeengekomen doorlooptijd van 15-35 weken. Daar ga je met je Sprints.

Virtualisatie en (hybride) Cloud omgevingen lossen veel op maar je moet nog steeds plannen en anticiperen en er moet ook bij een Cloud leverancier voldoende capaciteit zijn. Investeringen in ontwikkelstraten hebben impact op de change- en runkosten. En hoe meer ontwikkelomgevingen hoe complexer het versiebeheer wordt. Heb je te weinig omgevingen dan zullen projecten en changes het recht van de grootste, belangrijkste en sterkste doen laten gelden. Kortom, je kunt het niet snel goed doen.

Waar gebeurd: Een zware applicatie draaide in containers (virtuele servers) op Oracle Solaris hardware. De development servers waren al maanden overbelast omdat iedere ontwikkelaar een End of Day wilde testen op de eigen ontwikkelomgeving. De beheerder van de development omgevingen had dat niet echt onder controle en werd overvraagd. En kreeg geen budget voor extra hardware. Op een goede dag kwam hij naar mijn bureau en keek me slim aan. "Ik heb het opgelost, ik ga een extra container aanvragen. Daar kan ik 4 extra omgevingen in kwijt!”. Op mijn vraag waar die container gehost ging worden reageerde hij vaag. Wat ik bedoelde? Toen ik hem uitlegde dat die container gecreëerd zou gaan worden op dezelfde overbelaste hardware en het dus niets voor hem ging oplossen slofte hij terug naar zijn eigen desk.

In deze reeks artikelen gaan we in op de infra-kant van een ontwikkelstraat. Achtereenvolgens worden de volgende aspecten uitgewerkt:
  - Kenmerken van een ontwikkelstraat
  - Kenmerken van een applicatie
  - Weerslag op de omgeving waar de applicatie draait
  - Sizing van een omgeving
  - Refresh mechanisme in een ontwikkelstraat
  - Eisen over beschikbaarheid en de impact op infra

Deel I - Kenmerken van een ontwikkelstraat
Een ontwikkelstraat doorloopt twee domeinen, het Change domein en het Run domein. Het eerste domein is het rijk van de veranderaars. Hier lopen de projecten en de grotere changes die door de business of regelgevers zijn geïnitieerd. Het doel is om functionaliteit toe te voegen of aan te passen. Hier gebruikt men ontwikkel en test omgevingen die uitgegeven en beheerd worden door een Change Team.

Het Run domein is het domein van de beheerders. Hier draait de applicatie op de productie omgeving en test men een nieuwe release op de acceptatie omgeving. Behalve eventuele bugfixes en minor changes op productie, heerst er vooral stabiliteit.

In de praktijk vertroebelt dit nog wel eens omdat de Run afdeling ook een ontwikkel- of test-omgeving wenst om bugfixes te testen en een groot project de neiging heeft de acceptatie omgeving in te nemen en vast te houden (ik leg later uit hoe je dat kunt en moet voorkomen).

Hoe werkt een ontwikkelstraat?

Ontwikkelen
De applicatie of delen ervan worden ontwikkeld in een ontwikkelomgeving. Een of meerdere ontwikkelaars werken in dezelfde omgeving. Iedere dag wordt de laatste versie opgeslagen in het versiemanagementpakket (ook alle andere omgevingen door de hele ontwikkelstraat houden hun wijzigingen bij in dit pakket). Bij veel grote applicaties en programma’s waarin meerdere functionaliteiten parallel aan elkaar worden ontwikkeld en beheerd zijn er meerdere ontwikkelomgevingen actief.

Daarnaast komt het bijvoorbeeld in de financiële sector regelmatig voor dat een afdeling (zoals Finance Risk) onderzoek wil doen naar een bepaalde klant of een bepaalde keten en historie van transacties. Zij vragen om de installatie van een productiekopie van een specifieke datum of periode om op hun gemak het een en ander uit te pluizen. Vaak vindt dit voor het gemak en vanwege kosten plaats op een ontwikkelomgeving. Security vindt hier overigens iets van (komen we op terug).

Testen
Op de testomgeving(en) worden de verschillende ontwikkelde patches samengevoegd en wordt er functioneel en technisch getest. Bij complexe omgevingen wordt er regelmatig tegen een referentieomgeving aan getest om te kijken of de resultaten in de nieuwe patch overeenkomen met de lopende patch (reconciliatie). Als de complete patch wordt goed bevonden dan kan hij door naar de acceptatie omgeving. Na iedere test-run worden de resultaten teruggekoppeld aan de ontwikkelaars. Afhankelijk van de applicatie en change vinden testen op de Test-omgeving dagelijks (’s nachts) of wekelijks plaats. 

Acceptatie
De acceptatie omgeving valt onder het Run domein. De acceptie omgeving is functioneel en technisch een replica van de productie omgeving. In de voorbereidingen van een nieuwe release wordt deze uitgebreid op de acceptatie omgeving getest. Daartoe wordt de nieuwe software-versie samen met een installatiehandleiding en bijbehorend Runboek door Change overgedragen aan Run.

Run installeert deze versie op de acceptatie omgeving. Run medewerkers testen eveneens technisch en functioneel maar testen meestal langer en kijken bijvoorbeeld ook naar ‘memory leaks’. Bij bedrijf-kritische applicaties wordt op de acceptatie omgeving ook de ‘fail-over’ en de bijbehorende ‘fail-back’ getest.

Zodra de acceptatie testen door alle betrokken partijen zijn afgetekend kan deze versie van de applicatie in productie worden genomen. Na de release van de nieuwe versie op productie wordt de acceptatie omgeving vaak nog enige tijd gebruikt om bugfixes en productieproblemen na te spelen. Tot het tijd is om de volgende nieuwe release te gaan testen.

Productie
Uiteindelijk draait natuurlijk alles om de productieomgeving. Aan de hand van de inmiddels goed geteste en eventueel aangepaste installatie-handleiding en het Runboek wordt de applicatie op het productieplatform geïnstalleerd. Er worden vooraf voorzieningen getroffen voor een roll-back zoals back-ups en snapshots van de database, zodat er altijd kan worden teruggevallen op de laatste stabiele versie. Het Runboek beschrijft de hele procedure, tijdlijnen, beslismomenten en te nemen besluiten en acties.

Wat Change nog wel eens uit het oog verliest is dat er op een productieplatform ook onderhoud moet worden gepleegd. Het ontwikkelen en testen van maintenance tools en onderhouds-scripts is minstens net zo belangrijk als de applicatie zelf. Zoals archiving en purging om de databases niet groter te laten groeien dan noodzakelijk. Maar ook een goed onderhoud op workflows, End of Day jobs en rationaliseren van het aantal rapportages dat een systeem moet leveren kan een verschil van dag en nacht maken op de performance van een applicatie en het onderliggende platform.

Tenslotte voedt productie de ontwikkelstraat met kopieën van de productie-versie (inclusief kleine bugfixes door Run) en afslagen van de database. Dit wordt ook wel een ‘refresh’ genoemd.  

In het volgende artikel gaan we onder andere in op de kenmerken van een applicatie. De eisen omtrent  de periodieke refresh komen daar ook in aan de orde.