Change-validatie

Voordat een voorgestelde wijziging je repository of je releaseproces bereikt, kan FixControl haar valideren — en precies vastleggen wat die validatie bewees. Deze pagina beschrijft de twee validatie-omgevingen, hoe de keuze ertussen wordt gemaakt, en welk bewijs een run achterlaat.

FixControl kan wijzigingen valideren in geïsoleerde multi-container-omgevingen en, waar geconfigureerd, de validatie vóór release voortzetten binnen Kubernetes-omgevingen die de klant zelf beheert.

Wijziging (voorgesteld door een developer of door FixControls AI)
   ↓
geïsoleerde Docker-validatie                 (waar geconfigureerd)
   ↓
optionele validatie in je eigen cluster      (beleidsgedreven, via de FC Agent)
   ↓
bewijs bevroren in de goedkeuring
   ↓
je bestaande CI/CD-, Kubernetes- en Argo-controles

Geïsoleerde Docker-validatie

Waar multi-container-validatie is geconfigureerd (een instelling per organisatie, standaard uit, aangeboden als onderdeel van een pilot), draait FixControl de wijziging naast de services die de applicatie werkelijk nodig heeft:

Het Compose-bestand van de repository wordt gelezen als configuratie — nooit uitgevoerd. Elke service, image en optie passeert een strikt beleid: niet-ondersteunde of gevaarlijke constructies (host-mounts, privileged containers, poortpublicatie, build-instructies en meer) worden geweigerd, niet stilletjes overgeslagen. De regels in klanttaal staan onder Projecten → Omgevingen met meerdere containers.
Services starten in één geïsoleerd netwerk per run, zonder internettoegang en zonder toegang tot je broncode; de run wordt na afloop opgeruimd, en een sweeper verwijdert wat een gecrashte run achterlaat.
Image-referenties worden vóór de run opgelost naar digests, zodat het bewijs de exacte softwareversies noemt waartegen de wijziging slaagde.

Deze lane beantwoordt: bouwt de wijziging, slagen de tests, en gedraagt ze zich naast haar database, cache en achtergrondservices? Ze is snel, reproduceerbaar en wegwerpbaar.

Validatie in je eigen omgeving

Waar geconfigureerd tijdens pilot-onboarding gaat de validatie verder binnen je eigen Kubernetes-cluster, uitgevoerd door een validatie-runner die het installatiepakket van de FC Agent meelevert:

De opdracht om te draaien arriveert als een getekende, aflopende, single-use operatie die de agent uitgaand ophaalt; de workspace reist over hetzelfde kanaal. Je cluster wordt nooit blootgesteld aan FixControl.
De runner maakt een kortlevende testnamespace aan, start dezelfde gedeclareerde services, draait hetzelfde plan, en ruimt op. Hij is een aparte identiteit naast de agent, kan rollouts niet aanraken, en een admission-policy blokkeert zijn schrijfacties buiten de eigen testnamespaces.
Secret-waarden verschijnen nooit in FixControls opslag, operatie-payloads, logs of bewijs. Waar een validatie secrets nodig heeft, worden de koppelingen tijdens pilot-onboarding zo ingericht dat runs ernaar verwijzen bij naam en de waarden zelf in jouw cluster blijven.

Deze lane beantwoordt een andere vraag: gedraagt de wijziging zich in de omgeving waarin ze werkelijk gaat draaien — de runtime, policies en afhankelijkheden van jouw cluster. Het is niet de Docker-run in tweevoud.

Welke validatie draait

De keuze is beleidsgedreven en expliciet — per project geconfigureerd samen met je team tijdens pilot-onboarding, niet afgeleid:

Alleen Docker — de geïsoleerde lane is vereist.
Alleen in-cluster — validatie draait in jouw omgeving.
Docker, daarna in-cluster — de geïsoleerde lane draait eerst; pas na een groen resultaat draait de in-cluster lane. De poort vereist dan beide resultaten.

Twee eerlijkheidsregels gelden overal:

Een vereiste in-cluster-validatie wordt alleen vervuld door in-cluster-bewijs — een Docker-only groen wordt er nooit voor in de plaats gesteld.
Is een vereiste lane niet beschikbaar (bijvoorbeeld: de agent staat uit), dan faalt de run gesloten met een duidelijke reden. Er wordt niet zonder melding teruggevallen op een zwakkere validatie.

FixControl detecteert ook wanneer een repository duidelijk op Kubernetes mikt (Helm-charts, Kustomize, manifests) en legt dat signaal bij de run vast, zodat een Docker-only-validatie van een cluster-zware applicatie zichtbaar is voor wat ze is. Het signaal informeert; het wijzigt nooit stilzwijgend de geconfigureerde strategie.

Bewijs

Elke groene run legt vast:

de genormaliseerde omgevingsconfiguratie (een hash van de gevalideerde topologie),
de exacte image-digests waarmee de services draaiden,
het uitgevoerde plan (welke stappen liepen),
voor in-cluster-runs: waar hij draaide — agent, cluster, namespace, operatie.

Samen vormen deze de validatie-fingerprint van de run. Een gewijzigde patch, image, configuratie of plan levert een andere fingerprint op, zodat verouderd bewijs nooit meelift. Het resultaat — inclusief de fingerprint en, waar van toepassing, de resultaten per lane — wordt bevroren in de goedkeuring die erop steunt, en verschijnt in het deployment-provenance-spoor naast de goedkeuring en de rollout waartoe ze leidde.

Waar je governance-beleid het vereist, weigert de patch-poort een wijziging toe te passen waarvan de huidige versie geen passend groen bewijs heeft (zie Governance & beleid, verificatiebeleid).

Als validatie faalt

Een falen levert gestructureerd bewijs op, geclassificeerd naar soort:

Applicatiefouten — een rode test, een crash bij het opstarten, een service die nooit ready werd. Deze kunnen een nieuwe, door AI voorbereide revisie van de wijziging voeden, die van voren af aan door validatie en goedkeuring gaat.
Infrastructuurfouten — een image die niet binnengehaald kon worden, een onbereikbare runner, een verlopen operatie. Deze verschijnen als health-bevindingen voor een beheerder en veroorzaken bewust geen codewijziging: een kapotte omgeving is geen bug in je applicatie.

In beide gevallen blijft governance tussen analyse en uitvoering staan: een falen betekent nooit dat een niet-beoordeelde wijziging je systemen bereikt.

Zie ook: FC Agent · DevOps & CI/CD · Governance & beleid.