,

Hoe Victoria-ID software ontwikkelt en uitrolt: kwaliteit als vertrekpunt

Elke nieuwe functionaliteit die u als klant in het Victoria-ID platform tegenkomt, heeft een zorgvuldig traject doorlopen. Van het eerste idee tot de uitrol in uw productieomgeving. In dit artikel leggen we uit hoe ons ontwikkelproces werkt, waarom we het zo hebben ingericht en wat dat voor u als klant betekent. Ons doel: nieuwe functionaliteit…

Elke nieuwe functionaliteit die u als klant in het Victoria-ID platform tegenkomt, heeft een zorgvuldig traject doorlopen. Van het eerste idee tot de uitrol in uw productieomgeving. In dit artikel leggen we uit hoe ons ontwikkelproces werkt, waarom we het zo hebben ingericht en wat dat voor u als klant betekent.

Ons doel: nieuwe functionaliteit snel beschikbaar stellen, zonder in te leveren op stabiliteit en betrouwbaarheid.

Vier fasen, één doel

Het Victoria-ID platform wordt ontwikkeld volgens een gestructureerde Software Development Life Cycle (SDLC). Dit is de werkwijze die bepaalt hoe nieuwe software van idee naar productie gaat. Ons proces bestaat uit vier opeenvolgende fasen, elk met een eigen omgeving en een eigen kwaliteitsdrempel.

Fase A: Development — hier begint alles

Nieuwe functionaliteit wordt ontwikkeld in zogenaamde feature branches: afgeschermde werkomgevingen binnen onze codebase. Elke software engineer werkt op zijn eigen kopie van de code. Dit betekent dat nieuwe ontwikkelingen nooit direct invloed hebben op wat u als klant ziet of gebruikt.

De code in deze fase verandert continu en kan onstabiel zijn. Dat is geen probleem, het is onderdeel van het proces in deze fase. Hier wordt gebouwd, geprobeerd en verbeterd.

Fase B: Testing — kwaliteitscontrole door collega’s

Zodra een feature klaar is voor beoordeling, dient de ontwikkelaar een zogeheten pull request in via GitHub. Dit betekent: „ik stel voor deze code samen te voegen met de hoofdbranch.” Maar dat gebeurt niet automatisch.

Elke pull request wordt beoordeeld door minimaal twee andere ontwikkelaars: de peer review. Pas na goedkeuring wordt de code samengevoegd in de Beta branch en uitgerold naar de Beta-omgeving. Deze omgeving draait op AWS met MongoDB, exact dezelfde technologiestack als uw productieomgeving.

De Beta-omgeving is continu in beweging. Nieuwe features worden doorlopend samengevoegd. Dit maakt het de ideale omgeving om nieuwe functionaliteit vroeg te showcasen en feedback te verzamelen.

Peer review is geen formaliteit. Het is de eerste kwaliteitspoort: vier ogen zien meer dan twee.

Fase C: Acceptance — een maand testen zonder afleiding

Eenmaal per maand wordt de Beta-code overgebracht naar de Candidate-omgeving via een nieuwe pull request. Vanaf dit moment geldt een strikte feature freeze: er komen geen nieuwe functies meer bij. Alleen het oplossen van gevonden fouten (fixes) is nog toegestaan.

Gedurende een volledige maand wordt de Candidate-versie uitgebreid getest. Ons team doorloopt scenario’s, controleert integraties en valideert dat alles werkt zoals bedoeld. Dit is de laatste kans om problemen te ontdekken vóórdat code naar productie gaat.

De Candidate-omgeving draait eveneens op AWS en MongoDB en is opzettelijk zo ingericht dat deze zo dicht mogelijk de productieomgeving benadert.

Een selecte groep klanten en partners krijgt tijdens de Candidate-fase vroegtijdig toegang tot nieuwe functionaliteit. Zij testen rechtstreeks in de Candidate-omgeving en geven directe terugkoppeling. Hun bevindingen worden meegenomen vóórdat de release definitief wordt. Op deze manier combineren we technische kwaliteitscontrole met praktijkervaring — en zorgen we dat nieuwe functionaliteit niet alleen technisch werkt, maar ook in de dagelijkse praktijk van onze klanten.

Fase D: Production — stabiel en betrouwbaar

Na een succesvolle acceptatieperiode wordt de code eenmaal per maand overgebracht naar de Master branch: de productiecode die u als klant gebruikt. Tegen die tijd heeft de code minimaal een maand stabiel gedraaid in de Candidate-omgeving.

In de productieomgeving zijn uitsluitend hotfixes toegestaan: kleine, gerichte correcties voor kritieke problemen. Nieuwe features wachten altijd op de volgende releasecyclus. Zo blijft productie wat het moet zijn: stabiel, voorspelbaar en betrouwbaar.

Elke release naar productie vertegenwoordigt minimaal twee maanden aan ontwikkeling, review en testen.

Wat betekent dit voor u als klant?

Ons SDLC-proces is ontworpen vanuit één uitgangspunt: u moet kunnen vertrouwen op het platform. Dat vertaalt zich in een aantal concrete voordelen:

  • Voorspelbare releases. Nieuwe functionaliteit wordt maandelijks uitgerold. U weet wanneer updates komen.
  • Hoge stabiliteit. Code bereikt productie pas na uitgebreide review en een maand testen.
  • Snelle respons bij problemen. Kritieke issues worden opgelost via hotfixes, zonder te wachten op de volgende releasecyclus.
  • Transparantie. Via onze release notes houdt u bij wat er per release is gewijzigd of toegevoegd.

Vragen?

Heeft u vragen over een specifieke release, een nieuwe functionaliteit of over ons ontwikkelproces? Neem contact op met onze supportafdeling of raadpleeg de release notes.

Het Victoria-ID Software Development Life Cycle (SDLC) proces

Figuur 1: Overzicht van het Victoria-ID SDLC-proces met de vier fasen Development, Testing, Acceptance en Production.

Deze website gebruikt cookies. Door deze site te blijven gebruiken, accepteer je ons gebruik van cookies.  Meer informatie