DTAP en gefaseerd opleveren
Nieuwe functionaliteit wil je niet rechtstreeks van development naar productie schuiven, zeker niet als gebruikers, processen en data direct geraakt worden. Daarom werken we met gescheiden omgevingen en vaste controles tussen bouwen en livegang. DTAP maakt vrijgeven niet per definitie trager, maar wel beter beheersbaar.
Gescheiden omgevingen voor bouwen, testen en accepteren
Geautomatiseerde checks voordat iets verder mag
Een acceptatiefase zonder risico voor productie
Waarom dit ertoe doet
Van wijziging naar verantwoord live zetten
Zodra software bedrijfskritisch is, wil je niet dat een kleine wijziging pas in productie laat zien waar de zwakke plek zit. Gescheiden omgevingen helpen om functionaliteit in stappen te valideren. Development is de plek om te bouwen. De testomgeving toetst automatisch op Woordenboek · In het kortlintingLinting is het automatisch controleren van broncode op mogelijke fouten en afwijkingen van afgesproken coderegels, zonder de applicatie uit te voeren. De tool die deze controle doet, heet een linter.Lees meer, Woordenboek · In het korttype safetyType safety is de mate waarin een programmeertaal voorkomt dat een waarde wordt gebruikt op een manier die niet past bij het type ervan. Een typecontrole kan zulke fouten tijdens het programmeren, compileren of uitvoeren signaleren.Lees meer en andere checks. In acceptatie beoordelen Woordenboek · In het kortquality assuranceQuality assurance (QA) is het geheel aan geplande, structurele maatregelen waarmee een team bewaakt dat software aan afgesproken kwaliteitseisen voldoet.Lees meer, Woordenboek · In het kortproduct ownerEen product owner is binnen Scrum verantwoordelijk voor het maximaliseren van de waarde van het product en voor het beheer van de product backlog. Deze persoon bepaalt de volgorde van het werk en maakt het productdoel duidelijk.Lees meer of stakeholders of de opgeleverde functionaliteit ook echt doet wat nodig is.
Pas daarna gaat een wijziging naar productie. Die volgorde voorkomt niet alle risico's, maar maakt ze wel veel eerder zichtbaar. Dat is precies wat je wilt als live software direct onderdeel is van de dagelijkse operatie.
Ontwikkelproces
Hoe de route naar productie eruitziet
Vier omgevingen, ieder met een eigen rol
Developers bouwen en testen lokaal of in een ontwikkelomgeving waar experimenteren veilig kan zonder directe impact op gebruikers.
Nieuwe code doorloopt hier geautomatiseerde controles zoals linting, type-checking en aanvullende tests, zodat fouten eerder worden onderschept.
Deze omgeving lijkt op productie en is bedoeld om opgeleverde functionaliteit handmatig te beoordelen zonder risico voor de live-versie.
Pas na de eerdere controles komt functionaliteit live beschikbaar voor eindgebruikers en operationele processen.
Bij vrijgave houden we bij welke functionaliteit is opgeleverd. Op acceptatie en productie volgen we foutmeldingen en prestaties, zodat nieuwe issues sneller zichtbaar worden.
Hier ontstaat de wijziging
Development
Developers bouwen en testen lokaal of in een ontwikkelomgeving waar experimenteren veilig kan zonder directe impact op gebruikers.
Trade-offs en opbrengst
Veiliger releasen vraagt meer dan extra omgevingen
DTAP werkt alleen goed als de controles ertussen serieus worden genomen. Een acceptatieomgeving zonder echte beoordeling of een testomgeving zonder zinvolle checks geeft vooral schijnzekerheid. Daarom koppelen we omgevingen aan duidelijke rollen, kwaliteitsmomenten en Woordenboek · In het kortreleaseEen release is een herkenbare versie van software die is klaargemaakt om beschikbaar te stellen aan gebruikers. Zo'n versie bundelt een of meer gecontroleerde wijzigingen.Lees meer-afspraken.
Met die afspraken wordt duidelijk welke stappen en controles nodig zijn voor livegang. Je krijgt meer grip op wat wanneer is vrijgegeven, wat al gevalideerd is en waar een wijziging nog bijsturing nodig heeft. In de SmartFile-case zie je hoe een voorspelbaarder releaseproces direct samenhangt met vertrouwen in verdere doorontwikkeling.
Meer over OTAP
Wat dit je oplevert
Meer controle over de stap van ontwikkeling naar productie
Fouten eerder zichtbaar door automatische en handmatige checks
Duidelijkere vrijgavemomenten voor stakeholders en gebruikers
Een releaseproces dat beter past bij bedrijfskritische software
Veelgestelde vragen
Niet als het goed is ingericht. Het doel is niet om extra bureaucratie toe te voegen, maar om wijzigingen gecontroleerd en voorspelbaar door te voeren.
Omdat je opgeleverde functionaliteit wilt beoordelen in een omgeving die lijkt op productie, zonder direct risico voor live gebruikers en processen.
Nee. Geautomatiseerde checks zijn belangrijk, maar ze vervangen niet het moment waarop stakeholders of QA beoordelen of de functionaliteit inhoudelijk klopt.
Juist dan. Gescheiden omgevingen en duidelijke vrijgavemomenten helpen om veilig nieuwe wijzigingen door te voeren terwijl productie blijft draaien.
Staat je vraag hier niet tussen?
Neem contact op