Kwaliteit en delivery
Het platform wordt gebouwd door een klein team met intensieve inzet van AI-agents. Dat maakt geautomatiseerde controle geen luxe maar de voorwaarde om verantwoord snel te kunnen werken.
Teststrategie
| Soort | Omvang | Wat het bewaakt |
|---|---|---|
| Component- en unittests | Bij elke wijziging, verplicht vóór samenvoegen; 2.816 testbestanden | Gedrag van de interface, de bedrijfslogica en de bewakingen die afgesproken regels vastleggen |
| Isolatietests | Bij elke wijziging die de database raakt en elke nacht, tegen een echte database; 134 reeksen | Wie welke data mag zien — per rol getoetst |
| End-to-end | Na elke uitrol en elke nacht, in drie lagen van volledige reizen door de applicatie | Inloggen en de kritieke gebruikersroutes |
| Diepe rooktest | Na elke uitrol op de testomgeving | Inloggen, elk van de acht werkbladen openen, één generatie met het echte model, één rapport aanmaken en downloaden |
| Kwetsbare pakketten | Elke nacht | Of een pakket waarop het platform draait een bekend ernstig lek heeft |
| Modellen, opslag en dossier | Elke nacht | Of de modellijst klopt met die van de leverancier, of er bestanden in de opslag staan waar geen rapport meer bij hoort, en of het dossier consistent is |
| Zoekkwaliteit | Gelabelde meetset, met de hand gedraaid bij een wijziging aan het ophalen | Of het ophalen van bewijs nog even goed werkt |
De meetset voor zoekkwaliteit verdient toelichting: gelabelde vragen met een bekend juist antwoord, plus vragen waarop geen goed antwoord bestaat en het systeem dat ook moet zeggen. Daarmee is meetbaar of een wijziging de bewijsvinding verbetert of stilletjes verslechtert — in plaats van dat op gevoel te beoordelen. De meetset bevat klantmateriaal en staat daarom niet in de repository. Wie het ophalen wijzigt, draait de meting zelf en zet de uitkomst bij de wijziging.
De weg naar productie
De gouden regel: productie krijgt nooit een databasewijziging die niet eerst op staging is bewezen.
- Een wijziging gaat als voorstel naar staging.
- Daar worden de migraties toegepast en de isolatietests gedraaid.
- Twee poorten controleren de uitkomst:
- een volledigheidspoort die per migratie controleert dat hij daadwerkelijk is toegepast;
- een gelijkheidspoort die het schema van staging en productie vergelijkt.
- Pas daarna gaat dezelfde wijziging naar productie, langs dezelfde poorten.
- Na elke uitrol draait automatisch een rooktest die inlogt en controleert of de applicatie werkt; op de testomgeving volgt daarnaast de diepe rooktest uit de tabel hierboven.
Parallelle processen die dezelfde database raken worden geserialiseerd, zodat twee uitrollen elkaar niet kunnen overschrijven. Klaargezette wijzigingen gaan één voor één door een samenvoegrij die elke stap meldt, en een wijziging moet op de laatste stand van de testomgeving staan voordat hij erin gaat.
Eén basis voor het schema. Sinds 22 oktober 2026 bestaat het schema uit één basisbestand, gemaakt uit productie, plus de migraties die erna komen. Een lege databank is daarmee in één stap op te bouwen, met alle rechten uitgeschreven; een nieuwe tabel zonder eigen toegangsrechten wordt bij het bouwen afgekeurd. Zie Datamodel.
Vijftien werkstromen in de bouwstraat draaien op een vast tijdstip, in Nederlandse tijd met een reserve-start, en het resultaat van elke nacht staat de volgende ochtend op het interne statusbord. Een rode nachtrun staat daar binnen enkele minuten.
De bouwketen
De webapplicatie wordt gebouwd en lokaal ontwikkeld met Vite; de testreeks draait op een lichte testrunner zonder zware bouwlaag erboven. De bouwomgeving staat vast op één versie van het besturingssysteem, en een geautomatiseerde pakketbeheerder stelt wekelijks gebundelde updates voor. Elke nacht controleert een scan de pakketten waarop het platform draait op bekende kwetsbaarheden: een ernstig lek in wat draait kleurt de controle rood, en een scan die niets kon lezen telt niet als groen.
Poorten ontstaan uit incidenten
Elke geautomatiseerde poort hierboven komt voort uit iets dat één keer is misgegaan:
- Een uitrol waarna gebruikers niet meer konden inloggen → rooktest na elke uitrol.
- Twee parallel ontwikkelde wijzigingen waarvan er één stilletjes nooit op productie landde → volledigheidspoort op migraties.
- Een databasewijziging die een inlogpad dubbelzinnig maakte → structuurcontrole die daarop specifiek let.
Dat patroon — een incident wordt een permanente, geautomatiseerde controle in plaats van een eenmalige reparatie — is bewust beleid.
Besluitvorming
Architectuurkeuzes worden vastgelegd voordat ze gebouwd worden, inclusief de overwogen alternatieven, de nadelen van de gekozen route en de omstandigheden waaronder de keuze heroverwogen moet worden. Zie Architectuurbesluiten.