Bijna elke storing begint met een wijziging: een nieuwe versie, een aangepaste instelling, een gewijzigd proces. Daarom willen we van elke wijziging kunnen zien waarom we haar deden, wie haar controleerde en of ze deed wat we ervan verwachtten. Zo kun je een fout terugvoeren op een concrete verandering, en weet je wat er is gewijzigd voordat je gaat zoeken.
Twee soorten wijzigingen. Klantwijzigingen gaan over onze producten, diensten en de techniek eronder, inclusief klantspecifieke instellingen. Organisatiewijzigingen gaan over beleid, procedures, rollen en werkwijzen. De principes zijn gelijk, de uitvoering verschilt. Voor beide geldt: elke wijziging heeft een eigenaar die haar beoordeelt, coördineert, vastlegt en achteraf evalueert.
Alles loopt via een pull request
Bij code is de pull request ons vaste punt. Een wijziging komt niet rechtstreeks in de hoofdlijn, maar wordt als pull request voorgelegd. Daar leggen we vast waarom we haar doen, wat en wie het raakt en wat het plan is. Daarna volgt de beoordeling: wat is het effect op vertrouwelijkheid, integriteit, beschikbaarheid, kwaliteit en continuïteit, welke risico's horen erbij en past het bij contractuele en wettelijke eisen?
Op elke pull request kijkt eerst GitHub Copilot mee met een code review. Dat vangt veelgemaakte fouten vroeg af, maar het vervangt geen collega. Daarnaast checken we automatisch op bekende kwetsbaarheden in de onderdelen die we gebruiken, en staat een lijst met beveiligingsafspraken voor onze technologie vast in wat we "klaar" noemen.
Vier-ogenprincipe. Dit is onze kernafspraak: er gaat niets naar productie zonder goedkeuring van een tweede persoon. Wie de code schreef, keurt haar niet zelf goed. Raakt de wijziging onze beveiligingsdoelen, dan kijkt ook de Security Officer mee.
In de praktijk: een spoedwijziging mag vóór goedkeuring worden doorgevoerd als er iets kritieks is, maar wordt daarna alsnog beoordeeld.
Configuratie. Niet alleen code verandert, ook instellingen. Hoe we versies, bronnen en terugdraaien van configuratie vastleggen lees je in ons bericht over configuratiebeheer.
Gescheiden omgevingen. Ontwikkelen, testen en live draaien gebeurt in aparte omgevingen, op aparte servers. Ze lijken zoveel mogelijk op elkaar, behalve de data en de koppelingen met externe systemen. Zo test je iets echt voordat het klanten raakt, en komt alleen bevoegd personeel bij productie.
Hoe een release verloopt
We nummeren versies volgens vaste regels. Grotere updates zijn "minor"-versies (van 1.2 naar 1.3) en voor ons feitelijk de grote releases. Kleine verbeteringen en bugfixes zijn patches, waarvoor de procedure lichter is.
Voorbereiden. Versienummer aanpassen, beveiligingsupdates van onderdelen binnenhalen, debugcode verwijderen, nieuwe databasemigraties testen op een kopie van de testdatabase en de versie in minstens twee browsers proberen, waarvan één zonder extensies. Daarna gaat de code via een review naar de testomgeving, waar we nagaan of alles werkt, vooral de koppelingen.
Acceptatietest. Bij een minor release krijgt de klant bericht met de nieuwe functies en de duur van de test, die minimaal meerdere weken is. Wij mogen er niet op rekenen dat de klant onze bugs vindt. De klant beoordeelt of de software doet wat bedoeld of verwacht is. Bij een patch slaan we dit over.
Tijdstip kiezen. Buiten kantoortijden, het liefst zodat gebruikers er niets van merken. Degene die de release doet heeft daarna ruim de tijd om te reageren als er iets kapotgaat. Bij een minor release stemmen we het moment af met de klant en plannen we maximaal één releasemoment per week bedrijfsbreed. De klant krijgt bericht en in de applicatie staat een banner.
Uitrollen. Migraties testen we nog een keer op een kopie van de echte database. Moet er handmatig iets aan de database gebeuren, dan maken we eerst een extra back-up en loggen we de handeling. Voordat de laatste merge gebeurt, houden alle aanwezigen een go/no-go-moment: is alles gecontroleerd en is het nog verstandig om te releasen? Daarna controleren we live of alles bereikbaar is en de data klopt. De klant krijgt een releasemail met de wijzigingen.
Onderhoud van de server. Bij een minor release werken we ook het besturingssysteem bij, herstarten we indien nodig, controleren we of alles weer draait, of back-ups kloppen en of schijfruimte en geheugen gezond zijn.
Nieuwe omgeving. Voor een nieuwe omgeving volgen we een vast stappenplan: server bijwerken, een eigen gebruiker met beperkte rechten, een eigen configuratie met unieke wachtwoorden en poorten, een beveiligde verbinding, bescherming tegen herhaald inloggen en aansluiting op uptime- en logmonitoring. Doordat elke omgeving zo hetzelfde wordt opgebouwd, weet je wat je aantreft als je er later iets aan wijzigt.
Verbeteren. Na een release kijken we of de wijziging deed wat we wilden en of er bijwerkingen waren. Wat we daarvan leren, werken we uit zoals beschreven in continu verbeteren: een tegenvallende release leidt tot een verbeterpunt voor onze procedure, met een eigenaar.