De OTAP-straat uitgelegd.

Waarom je niet rechtstreeks op productie ontwikkelt

Het klinkt logisch: je wilt een wijziging doorvoeren, dus je past de code aan op de live server. De klant ziet het resultaat meteen, je hoeft niets te deployen en het is snel geregeld. Wat kan er misgaan?

Alles. Alles kan er misgaan.

Een typfout in een query en je database is corrupt. Een vergeten puntkomma en je applicatie geeft een witte pagina. Een nieuwe feature die half werkt en je klanten krijgen foutmeldingen. En het ergste: je hebt geen manier om terug te gaan naar de vorige situatie, want die bestaat niet meer.

De OTAP-straat voorkomt dat. Het is een gestructureerde manier om software te ontwikkelen, testen en op te leveren — zodat je gebruikers alleen gevalideerde, werkende software te zien krijgen.

De vier omgevingen

O — Ontwikkeling (Development)

Dit is waar de code wordt geschreven. De lokale machine van de developer, met een eigen database, eigen configuratie en eigen testdata. Hier mag alles kapotgaan — dat is het hele punt. Je experimenteert, bouwt, breekt en fixt. Niemand heeft er last van behalve de developer zelf.

Kenmerken van de ontwikkelomgeving:

• Draait lokaal op de machine van de developer
• Eigen database met testdata (nooit productiedata)
• Debug-modus aan, uitgebreide foutmeldingen
• Externe diensten worden gemockt of draaien in sandbox-modus
• Snelle feedbackloop: wijziging opslaan, browser verversen, resultaat zien

T — Test (Testing / Staging)

Zodra een feature af is en lokaal werkt, gaat het naar de testomgeving. Dit is een server die productie zo veel mogelijk nabootst, maar met testdata. Hier draaien de geautomatiseerde tests: unit tests, feature tests, integration tests. En hier test de developer of alles samenhangt.

Kenmerken van de testomgeving:

• Draait op een server (niet lokaal)
• Configuratie die productie nabootst (dezelfde PHP-versie, dezelfde database-engine, vergelijkbare server-specs)
• Testdata die representatief is voor de echte situatie
• Automatische deployments via CI/CD pipeline
• Niet toegankelijk voor eindgebruikers

A — Acceptatie (Acceptance / UAT)

Dit is de omgeving waar de opdrachtgever of eindgebruiker de nieuwe functionaliteit test en goedkeurt. De acceptatieomgeving draait de meest recente goedgekeurde code en biedt de klant de mogelijkheid om te valideren: doet het wat ik heb gevraagd? Werkt het zoals verwacht? Klopt de flow?

Kenmerken van de acceptatieomgeving:

• Toegankelijk voor de opdrachtgever en stakeholders
• Representatieve data (anoniem gemaakte productiedata of realistische testdata)
• Geen debug-modus, geen technische foutmeldingen
• De plek waar de klant "akkoord" geeft voordat het naar productie gaat
• Soms gecombineerd met de testomgeving bij kleinere projecten

P — Productie (Production)

De live omgeving. Hier werken de echte gebruikers met echte data. Alleen code die door alle voorgaande stappen heen is gekomen, bereikt productie. Geen experimentele features, geen half werkende functionaliteit, geen ongeteste wijzigingen.

Kenmerken van de productieomgeving:

• De live applicatie die eindgebruikers bedienen
• Echte data, echte gebruikers, echte gevolgen
• Uitgebreide monitoring en logging
• Automatische backups
• Beveiligd en verhard (geen debug-modus, geen overbodige poorten, geen testaccounts)
• Zero-downtime deployments

De flow: van links naar rechts

Code stroomt altijd in één richting: van O naar T naar A naar P. Nooit andersom. Nooit een stap overslaan. Dit is de discipline die ervoor zorgt dat productie stabiel blijft.

1. Developer schrijft code en test lokaal (O)
2. Code wordt gepusht en automatische tests draaien (T)
3. Bij succes wordt de code op de acceptatieomgeving gezet voor review (A)
4. Opdrachtgever test en geeft akkoord
5. Code wordt naar productie gedeployed (P)

Bij urgente hotfixes — een kritieke bug in productie — mag je de route versnellen, maar nooit stappen overslaan. Zelfs een hotfix gaat door tests en wordt gevalideerd voordat het live gaat.

De OTAP-straat is geen bureaucratie. Het is de reden dat je klanten nooit een half werkende feature te zien krijgen.

Hoe ik het inricht

Bij Coding Agency werk ik standaard met minimaal drie omgevingen: lokale development, staging/acceptatie (gecombineerd) en productie. Bij grotere projecten of projecten met meerdere stakeholders splits ik staging en acceptatie.

Praktisch voorbeeld

Voor een typisch Laravel-project ziet dat er zo uit:

• Lokaal — Laravel Valet of Herd op mijn machine. Eigen database, eigen .env-configuratie.
• Staging — Een aparte omgeving op dezelfde infrastructuur als productie. Bereikbaar via staging.jouwapp.nl. Automatische deployment bij elke merge naar de develop branch.
• Productie — De live applicatie op jouwapp.nl. Deployment bij merge naar de main branch, na goedkeuring op staging.

Bij serverless projecten via Laravel Vapor is dit nog eenvoudiger: Vapor ondersteunt meerdere omgevingen out-of-the-box, elk met eigen configuratie, database en domein.

Veelgemaakte fouten

• Geen staging-omgeving — Rechtstreeks van development naar productie. "We testen het wel live." Tot het fout gaat en je klanten het als eerste merken.
• Staging die niet op productie lijkt — Staging draait op een andere PHP-versie, een andere database of met andere configuratie. Alles werkt op staging, maar breekt op productie. Het hele punt van staging is dat het productie nabootst.
• Productiedata op staging — Een kopie van de productiedatabase op staging, compleet met echte klantgegevens. Dat is een AVG-overtreding en een beveiligingsrisico. Gebruik anoniem gemaakte data of synthetische testdata.
• Stappen overslaan bij haast — "Het is maar een kleine wijziging, ik zet het even direct op productie." Beroemde laatste woorden. Kleine wijzigingen veroorzaken de meeste productie-incidenten.
• Handmatige configuratieverschillen — Environment-specifieke configuratie die handmatig op de server wordt ingesteld in plaats van in code. Na een herinstallatie weet niemand meer welke instellingen nodig zijn.

OTAP voor kleinere projecten

Niet elk project heeft vier volwaardige omgevingen nodig. Voor kleinere projecten is een pragmatische variant:

• Minimaal — Lokaal + Productie. Beter dan niets, maar je mist de veiligheidslaag van staging.
• Standaard — Lokaal + Staging + Productie. Mijn standaard voor de meeste projecten. Staging dient als test- én acceptatieomgeving.
• Volledig — Lokaal + Test + Acceptatie + Productie. Voor projecten met meerdere stakeholders, compliance-eisen of complexe release-processen.

Het minimale is altijd: ontwikkel nooit op productie. Er moet minimaal één omgeving tussen development en productie zitten.

De kosten

Een staging-omgeving kost geld: een extra server of een extra Vapor-environment. Reken op € 20 tot € 100 per maand, afhankelijk van de infrastructuur. Dat is een fractie van de kosten van een productie-incident dat je had kunnen voorkomen.

Bij Laravel Vapor zijn extra omgevingen bijzonder goedkoop: je betaalt alleen voor daadwerkelijk gebruik. Een staging-omgeving die alleen actief is tijdens development kost vaak minder dan € 10 per maand.

Tot slot

De OTAP-straat is geen theoretisch model uit een handboek. Het is een praktische manier om ervoor te zorgen dat je software betrouwbaar is, dat wijzigingen gecontroleerd worden doorgevoerd en dat je gebruikers nooit last hebben van ongeteste code.

Bij elk project dat ik oplever, is een werkende OTAP-straat (of een pragmatische variant daarvan) onderdeel van de oplevering. Omdat software bouwen niet alleen gaat over code schrijven — het gaat over die code veilig bij je gebruikers krijgen.