Introductie op Continuous Compliance

Andreas Prins
Continuous wat…. de zoveelste continuous zul je misschien denken? Jazeker na continuous improvement, continuous integration, build en deployment is er meer. Continuous Compliance is misschien voor veel bedrijven van groter belang dan de voorgaande drie. En dan nog een term erbij om het rijtje compleet te maken: Zero Touch Evidence.

In een serie van 4 blogs wil ik uiteenzetten wat in mijn ogen een grote ontwikkeling is die we door moeten maken. Een ontwikkeling die banken, verzekeraars en alle andere bedrijven die aan audits onderhevig zijn door gaan op termijn. Contiuous Delivery is leuk en handig als je het op orde hebt maar is slechts een speeltje van IT als je het tweede deel Continuous Compliance niet inricht.

In deze serie van 4 blogs worden de volgende zaken uitgelegd:

Introductie op Continuous Compliance

Continuous Compliance is de uitkomst van de inrichting van het voortbrengingsproces van software waarbij elke stap geautomatiseerd bewijslast oplevert en ook zelf zo is ingericht dat onomstotelijk kan worden vastgelegd hoe een change is uitgevoerd.
Wanneer heb je continuous compliance berijkt? Als je de partij die de audit komt uitvoeren zonder het zoeken en verzamelen van bewijslast deze kunt opleveren: Zero Touch Evidence.

De oplevering van deze bewijslast bestaat primair uit twee aspecten.

  1. Bewijslast over het voortbrengingsproces, je wilt van elk willekeurig moment dat je een verandering hebt doorgevoerd op de software weten hoe op dat moment je Continuous Delivery Pipeline eruit zag en wie er de veranderingen heeft doorgevoerd.
  2. Bewijslast van elke stap in het voortbrengingsproces, je wilt een verandering van je code naar productie brengen en wilt daarbij van de benodigde stappen vastleggen wat er is gebeurt.
Continuous Compliance gaat er vanuit dat Continuous Delivery (CD) volledig is ingericht. Ben je benieuwd wat dit precies inhoudt? Het boek van Jez Humble en Dave Farley geeft hier een perfect antwoord op. Een echte aanrader als je hier nog niet in thuis bent. >> Ga direct naar Bol.com.

Continuous Compliance bouwt voort op de schouders van CD. CD moet dan zo ver zijn ingericht dat je volledig geautomatiseerd een verandering van je code met 1 druk op de knop van je lokale developement omgeving in productie kan krijgen. Dit op orde hebben noemde ik eerder het speeltje van IT (ik realiseer me erg goed hoe moeilijk dit is, welke effort, offers en inspanning dit kan kosten). Heb je het compliance onderdeel niet in op orde dan ga je onderuit. Je gaat onderuit op je risk levels en je inspanning om bewijslast op te leveren. Daarover later meer.

Introductie op Continuous Delivery

Bewijslast over het voortbrengingsproces

Heb je wel eens een audit gehad op je voortbrengingsproces dan weet je hoe vervelend het is als er zaken niet op orde zijn. Het vraagt aanpassing van je proces of in het slechtste geval allerlei procedurele controles die de uiteindelijke levering van software (helaas) niets veiliger maakt.
Continuous Compliance is een proces dat zo is ingericht dat je altijd weet:
  • Wie, wanneer, welke wijziging heeft aan gebracht in de CD pipeline
  • Dat er geen wijziging van code kan plaatsvinden in productie anders dan via de CD Pipeline
  • Dat de pipeline zelf de controles afdwingt zonder daar een procedure naast te hebben die dat controleert

Bewijslast uit elke stap in het voortbrengingsproces

Naast logging op je proces moet je elke keer bij de uitvoering van dit proces automatisch de resultaten loggen. Door dit op een gestructureerde manier weg te schrijven kun je het later ook eenvoudig doorzoeken. Bijna uit elke stap van je CD pipeline heb je wel resultaten die je wilt loggen.
Daarnaast moet het proces zich afbreken in welke fase dan ook als er niet wordt voldaan aan kwaliteitseisen. Niet achteraf een controle doen, of tevreden zijn met “90% goed is ook goed” en het dan toch doordrukken naar productie. Als je echt wilt streven naar Zero Touch Evidence moet je het ook echt goed doen tijdens de uitvoering. En ja, dat vraagt om wat investering bij elke release, maar als je toe wilt naar een release per sprint, of zelfs per dag dan zul je geen andere keuze hebben.
Enkele concrete voorbeelden van bewijslast uit elke stap in de release:
  • Logging welke CI’s gedeployed worden
  • Welke testsoorten zijn uitgevoerd, note: de uitkomst is ALTIJD positief anders is de build of deployment gestopt
  • Logging wie de peer review heeft uitgevoerd, note: deze is ALTIJD uitgevoerd het proces schrijft dat voor door bijvoorbeeld een 2e goedkeuring bij merge naar Master Branch via een Gitflow.

Continuous Compliance by default

Een goede Continuous Compliance Pipeline dwingt het default al af, het is simpel je kunt niet anders dan de software op deze manier naar productie brengen. Het is mijn stellige overtuiging dat dit ook de enige manier is om de kwaliteit echt op orde te krijgen en incidenten drastisch te verminderen.

Na deze introductie gaat de volgende blog in op de noodzaak van Continuous Compliance. Het waarom achter deze blog heb je dus nog tegoed!

Ben jij hier ook mee bezig? Deel dan hier je reactie zodat het verhaal nog scherper wordt.

 

whatsapp meWil je een WhatsApp bericht ontvangen bij een nieuwe blog?
Stuur dan even een berichtje naar +31645112490

3 thoughts on “Introductie op Continuous Compliance”

  1. Pingback: De Introductie op Continuous Compliance | Agile...

  2. Hi Andreas,

    Goed stuk! Je noemt een paar keer de zware inspanningen diue ervoor nodig zijn om tot CD / CC te komen. Kun je inzicht geven in wat er allemaal bij komt kijken?
    Of bewaar je dat voor een volgende blog? 😉

    • Hoi Anko,
      Daar gaat het volgende blog onder andere over. Maar kort gezegd 1 je moet het in de mindset krijgen van je team 2 je moet met risk afdelingen aan de bak voor goedkeuringen en proces aanpassingen 3 grote technologie component.

Comments are closed.