3/5/2023

De OTAP-ontwikkelstraat: vier fases uitgelegd

De term OTAP zie en hoor je tegenwoordig geregeld langskomen in IT-kringen. Hij staat bijvoorbeeld vaak in richtlijnen of hostingcontracten. Het begrip heeft betrekking op een methode en filosofie voor het ontwikkelen van software en bevat de eerste letters van de fasen die je doorloopt bij het uitvoeren van een softwareproduct: ontwikkeling, test, acceptatie en productie.

Een ontwikkelomgeving waarin we gebruikmaken van deze werkwijze heet een OTAP-ontwikkelstraat. Vergelijk het met het idee achter een wasstraat voor je auto. In elke fase van het proces voer je bepaalde handelingen op een gestandaardiseerde manier uit, waardoor je de continuïteit, veiligheid en efficiëntie van het proces borgt. Maar wat houden de verschillende fases van een OTAP-ontwikkelstraat precies in? En wat is de belangrijkste winst die je boekt met deze werkwijze? In dit artikel leggen we het uit.

Waarom een OTAP-ontwikkelstraat?

De onderverdeling die aan de basis staat van OTAP lijkt een voor de hand liggende. Toch hebben veel websites, applicaties en webtoepassingen (zeker als ze wat ouder zijn) geen OTAP-straat. In plaats daarvan werken ze met één versie van de website of applicatie (de live-versie) die op een webserver staat. Aanpassingen doe je direct in de liveversie, waardoor je de veranderingen die je doorvoert direct terugziet.

Het nadeel van deze aanpak? De live-versie kan kapot gaan of eruit komen te liggen als je nieuwe code of aanpassingen test, zeker als een website of -applicatie druk bezocht wordt of als er meerdere mensen tegelijk aan werken. Werken met een OTAP-straat voorkomt dit probleem, omdat de ontwikkel-, test- en productieomgeving losstaan van de live-omgeving. Je kunt de omgevingen dus prima afschermen van de buitenwereld en veilig experimenteren met nieuwe technieken en aanpassingen. Bezoekers en gebruikers van een applicatie merken hier niets van.

De vier fases van de OTAP-straat

Een OTAP-straat heeft vier fases. Tijd om die eens nader te bekijken en toe te lichten wat er in elke fase gebeurt.

Fase 1: Ontwikkelen

De reis door de OTAP-straat begint in de ontwikkelomgeving. Die bevindt zich meestal op de laptop of desktop van de diverse ontwikkelaars. Een of meerdere personen werken in de ontwikkelomgeving aan een gezamenlijke versie. Via een versiebeheersysteem (denk aan Git) staat de lokale ontwikkelomgeving in contact met alle personen die bij het project betrokken zijn. Iedereen die aan het project meewerkt en de juiste credentials en machtigingen heeft, kan veranderingen doorvoeren of nieuwe onderdelen toevoegen aan de applicatie.

In Git werkt dit proces bijvoorbeeld als volgt: wanneer een ontwikkelaar aanpassingen doet aan de broncode, stuurt hij of zij wijzigingen door naar een centrale plek online. Met behulp van speciale ‘revisiesoftware’ kun je hier alle veranderingen volgen en documenteren. Dit maakt het mogelijk om wijzigingen te controleren en te testen, maar ook om ze eventueel terug te draaien of af te wijzen. Aan het eind van de dag kopieer je de actueelste versie in het zogenoemde versiebeheerprogramma op de ontwikkelserver.

Fase 2: Testen

Je wilt natuurlijk weten hoe gedane aanpassingen zich vertalen naar de praktijk voordat je de wijzigingen definitief doorvoert in de liveversie. In de testomgeving kun je precies nagaan hoe de nieuwe code werkt op een webserver. De testserver geeft je de mogelijkheid om zowel technisch als functioneel te testen. Je kunt bijvoorbeeld onderdelen aan- of uitzetten en kijken welk praktisch effect dit sorteert.

De resultaten van het testwerk zet je vervolgens klaar voor de ontwikkelaars, die er de volgende dag mee aan de slag kunnen. Zet je een release voort? Dan kunnen alle betrokken developers en stakeholders die uitgebreid testen. Specialisten op het gebied van OTAP-hosting kunnen bovendien de invloed van hardware in testomgevingen nauwkeurig in kaart brengen.

Fase 3: Acceptatie

Komt de code succesvol door de testfase? En zijn de uitgevoerde aanpassingen naar wens? Dan kun je de applicatie en nieuwe functionaliteiten doorzetten naar de acceptatieomgeving, een stap die je zorgvuldig documenteert in een draaiboek. De acceptatieomgeving is op het gebied van hard- en software zoveel mogelijk in overeenstemming met de productieomgeving.

Tijdens de acceptatiefase krijgen de niet-ontwikkelaars nieuwe functionaliteiten of vormgeving voor het eerst te zien. Alle stakeholders kunnen het resultaat bekijken zonder dat dagelijkse werkzaamheden onderbroken worden. Voldoet het opgeleverde resultaat aan de verwachtingen? Dan kun je de code doorzetten naar de productieomgeving.

Fase 4: Productie

De productieomgeving is het laatste deel van de OTAP-ontwikkelstraat. Hier implementeer je de applicatie en zijn bezoekers en gebruikers voor het eerst actief bezig met de nieuwste versie. Alle aangebrachte wijzigingen gaan dus live.

Het is belangrijk dat je in deze fase van de OTAP-straat een plan hebt om wijzigingen eventueel terug te draaien. Zo kun je bij onvoorziene problemen de productie-installatie ongedaan maken en alles terugzetten naar de oude versie. In de productieomgeving is downtime een belangrijk aandachtspunt. Om de impact van downtime in kaart te brengen en te beperken, kun je de begrippen recovery time objective (RTO) en recovery point objective (RPO) toepassen.

Een efficiënte OTAP-straat inrichten?

Zoals je ziet zorgt een OTAP-straat ervoor dat developers op een efficiënte, beheersbare en veilige manier nieuwe releases en patches kunnen implementeren. Je voorkomt onaangename verrassingen bij de livegang door fouten vroegtijdig op te sporen en te herstellen, bespaart kosten door meer efficiëntie en voorspelbaarheid en maximaliseert de uitwisselbaarheid van developers tussen verschillende projecten.

Wij hebben ruime ervaring in het opzetten en beheren van een OTAP-straat voor tal van organisaties. Met Managed OTAP profiteer je van een cloudonafhankelijk (je kunt in elke fase kiezen voor on-premises, een public cloud, een private cloud of een combinatie van verschillende clouds) en gestandaardiseerd OTAP-proces. Security by design, correctief en proactief beheer van onze kant, een multidisciplinair team, monitoring, logging en korte communicatielijnen zorgen ervoor dat je het beste haalt uit de OTAP-methodiek en zonder zorgen kunt focussen op de verdere ontwikkeling van je software.

Deel deze post
Paul Bijleveld
Paul Bijleveld is Managing Director en Senior Partner bij ACC ICT. Hij houdt zich bezig met het uitzetten van de strategie, de ontwikkeling van de organisatie én collega's en de innovatie van cloudinfrastructuren. Om fit te blijven sport hij 3x per week. Driften vindt hij de allerleukste activiteit in de regen. Paul schrijft graag over complexe IT-vraagstukken die herkenbaar zijn voor veel organisaties.