Alles dat je moet weten over OTAP

Alles dat je moet weten over OTAP

Binnen de developers wereld is OTAP een begrip. werken met OTAP is voor vele developers iets dat vrijwel automatisch gaat. Maar wat is het nou precies, hoe zet je zoiets op en, gezien het niet een hele nieuwe methode is, is het nog wel van deze tijd?

Wat is OTAP

De afkorting OTAP (In het Engels DTAP) staat voor Ontwikkeling, Test, Acceptatie en Productie. Het helpt software engineers om te weten in welke fase de ontwikkeling van een bepaald stuk software zit. De OTAP-straat doorloopt vier fases. OTAP kan ook gebruikt worden om efficiënt en overzichtelijk releases en patches te implementeren. De vier fases van de ontwikkelstraat zien er als volgt uit.

Fase 1: Ontwikkelen

De applicatie of een onderdeel daarvan, wordt eerst ontwikkeld in een speciale ontwikkelomgeving. Hier bevinden zich veelal één of meerdere personen in een ontwikkelteam die werken aan één gezamenlijke versie. Belangrijk hierbij is het registreren van de verschillende versies.

Fase 2: Testen

Vaak wordt het gemaakte stuk code overgezet naar een testomgeving. Op deze omgeving kan zowel technisch als functioneel getest worden. Dit kan in de nacht, dan liggen de resultaten de volgende dag klaar voor het ontwikkelteam. Maar het kan ook overdag en dan moeten developers soms verder met andere functionaliteiten, totdat de tests zijn voltooid. Wanneer er een release wordt voortgezet, kan deze release volledig worden doorgetest door alle betrokken partijen.

Fase 3: Acceptatie

Na goedkeuring kan de applicatie worden geïnstalleerd in de acceptatieomgeving. Dit wordt zorgvuldig gedocumenteerd in een draaiboek. De acceptatieomgeving is, qua hard- en software, gelijk aan de productieomgeving. Hierdoor kan gekeken worden of alles werkt zonder dat het dagelijks gebruik beïnvloed is.

Fase 4: Productie

Nadat de applicatie is geaccepteerd, wordt de applicatie geïmplementeerd binnen de productieomgeving.

Hoe implementeer je OTAP

Je OTAP omgeving draait vaak op een externe server, zoals het Azure Devops van Microsoft. Maar je kunt er ook voor kiezen om het zelf te hosten, dat kan bijvoorbeeld met Teamcity van Jetbrains. Er zijn heel veel pakketten te kiezen. Maar uiteindelijk komt het erop neer dat je een aantal ‘builds’ configureert die een gedeelte of je hele codebase kunnen deployen naar een omgeving. Iedere build heeft meerdere build steps. Een hele simpele build, naar bijvoorbeeld een acceptatie omgeving, zou kunnen bestaan uit 3 stappen:

• Haal de code op uit je version-control system
• In deze stap wil je wellicht wat omgeving-specifieke fixes toepassen binnen je code, of voer je een script uit om je code te zippen
• Deploy de code naar de acceptatie omgeving

De al eerder genoemde tools hebben hier een hele handige interface voor. Je kunt vaak door alleen rond te klikken een hele OTAP straat inrichten. Vaak zul je zien dat bij grotere en complexe projecten nog extra stappen nodig zijn, waar je zelf een script voor zult moeten schrijven. Maar ook dit zijn vaak kleine scripts die in stappen werken.

Is OTAP nog van deze tijd?

In een OTAP omgeving moet je, voordat je toe bent aan productie, bij elke omgeving een aantal stappen herhalen. Er zijn daarvoor een aantal best practices die er voor zorgen dat OTAP goed kan werken.

Zo is het handig om er voor te zorgen dat de hele ontwikkelstraat al aanwezig is, er veel getest kan worden met actuele data en is het slim om de klant te betrekken bij het hele proces.

Tegenwoordig is het zo dat de ‘testers’ en de ‘ontwikkelaars’ geen afgebakende taken meer zijn. Het hele project wordt in teamverband uitgevoerd en iedereen is verantwoordelijk voor het testen en ontwikkelen van de software. Mede door zo’n nieuwe rolverdeling kunnen processen als OTAP natuurlijk altijd efficiënter.

Als we een kijkje in de toekomst nemen dan zal OTAP vervangen worden door een containersysteem. Hierbij is het idee dat je systeem uit meerdere kleinere subsystemen bestaat. Het is dan de bedoeling dat je het hele systeem, inclusief de subsystemen door de hele OTAP haalt. Je deployed dan dus vier keer het hele systeem. Daarnaast kun je ook ieder individueel subsysteem los testen en dan hoef je niet met je hele systeem door de vier stappen van OTAP. Dit scheelt tijd en is dus goedkoper.

Zeker voor grotere bedrijven is het lastig om zomaar van een OTAP omgeving af te stappen, dus de verwachting is dat OTAP nog wel even blijft bestaan.

In conclusie

OTAP staat dus voor ontwikkelen, testen, acceptatie en productie. Je OTAP omgeving draait vaak op een externe server en het bouwen van de verschillende omgevingen bestaat vaak uit drie stappen. OTAP is een methode die vandaag de dag nog vaak wordt gebruikt, zeker bij de grotere bedrijven. We verwachten alleen wel dat een containersysteem OTAP zal vervangen.

Is OTAP voor jou niks vreemds, ben je developer en op zoek naar een nieuwe carrière? Neem dan eens een kijkje op onze vacature pagina! Of lees de blog over het werk van een DevOps Engineer.

Colin Hamer

Colin Hamer is Software Engineer bij CaseNine. Hij is verantwoordelijk voor diverse Salesforce projecten bij klanten.