De OTAP-ontwikkelstraat: vier fases

De afkorting OTAP staat voor ontwikkeling, test, acceptatie en productie. Het is een methode voor het ontwikkelen van software. In een ontwikkelomgeving, de OTAP-ontwikkelstraat, doorloopt een ontwikkelteam vier fases. OTAP kan ook wel gezien worden als een werkwijze die zorgt dat er op efficiënte en beheersbare wijze nieuwe releases en patches geïmplementeerd worden. Het belang van kwalitatief sterke OTAP-Omgeving en continuïteit in de ontwikkelomgeving mag niet worden onderschat. De vier fases zijn essentieel.

De vier fases van de OTAP-ontwikkelstraat zijn als volgt:OTAP

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. Aan het einde van elke dag wordt deze versie gekopieerd in het ‘versiebeheerprogramma’ op de ontwikkelserver.

Zorgenloos programmeren zonder zorgen over Operations? Kijk dan bij Turnkey OTAP »

Fase 2: Testen
Die gezamenlijke applicatieversie wordt ‘s nachts automatisch van programmacode naar een functionerende applicatie omgezet en eventueel doorgezet naar een testserver. Op de testserver kan zowel technisch als functioneel getest worden. De resultaten liggen de volgende dag klaar liggen voor het ontwikkelteam. Wanneer er een release wordt voortgezet, kan deze release volledig worden doorgetest door alle betrokken partijen. Een specialist op het gebied van OTAP-hosting kan de invloed van de hardware in de ontwikkelomgeving op tests in kaart brengen.

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, zoveel mogelijk gelijk aan de productieomgeving. In deze fasen kunnen functionaliteiten en performance bekeken worden door de betrokken partijen, zonder dat de dagelijkse productie hierin onderbroken wordt. 

Fase 4: Productie
Nadat de applicatie is geaccepteerd, wordt de applicatie geïmplementeerd binnen de productieomgeving. Dezelfde procedure wordt gevolgd als tijdens het overzetten van de testomgeving naar de acceptatieomgeving. Een plan om terug te draaien is voorbereid, zodat het ontwikkelteam bij onvoorziene omstandigheden de productie-installatie ongedaan kan maken en de oude versie terug kan zetten. 

In de productieomgeving is de impact van downtime groot. Om te bepalen hoe belangrijk het is deze impact te verkleinen, bieden de begrippen Recovery Time Objective (RTO) en Recovery Point Objective (RPO) uitkomst. ACC ICT heeft in haar datacenteronafhankelijke infrastructuur veel maatregelen genomen om de beschikbaarheid van productieomgevingen op 99,999 procent te bepalen.

Zorgenloos programmeren en zelf het beheer kunnen doen? Kijk dan bij Managed OTAP »

Wilt u meer weten over de ontwikkelstraat en Managed OTAP? Vul het onderstaande formulier in en ontvang ons whitepaper over dit onderwerp.

Terug naar het laatste nieuws