In veel Belgische overheidsinstellingen is continue implementatie technisch gezien mogelijk, maar releases blijven zeldzaam. De reden hiervoor ligt zelden bij de pipeline. Het is de angst om een functie aan gebruikers bloot te stellen voordat deze klaar is. Wanneer het uitbrengen van code en het inschakelen ervan één en dezelfde handeling zijn, brengt elke release een risico met zich mee dat niets met de code te maken heeft.
We hebben samengewerkt met een grote Belgische federale overheidsinstelling om die twee handelingen van elkaar te scheiden: code continu implementeren en afzonderlijk beslissen wanneer deze moet worden geactiveerd. Het middel hiervoor waren feature flags, die geleidelijk werden ingevoerd in plaats van verplicht te worden gesteld. Vandaag de dag maken 15 van de 17 technische teams er in de productie gebruik van.
Download de PDFHet uitgangspunt
De instelling beschikte al over een moderne CI/CD-basis. De knelpunt lag op operationeel vlak: hoe kun je meerdere keren per dag implementeren zonder functies bloot te stellen die nog niet af zijn of onstabiel zijn? Het betrof 17 technische teams, enkele duizenden gebruikers verderop in de keten en een Java/Angular-platform op OpenShift.
Bij elke release deden zich dezelfde problemen voor. Teams aarzelden om te implementeren uit angst dat er onafgewerkte code openbaar zou worden gemaakt. Er was geen manier om een functie eerst bij een subgroep van gebruikers te testen, er was geen centraal overzicht van wat er in ontwikkeling was en er was geen vangnet om trunk-based development toe te passen. Implementatie en release waren nog steeds onlosmakelijk met elkaar verbonden.
Wat we hebben gedaan
In plaats van de tool in één keer bij 17 teams in te voeren, zijn we begonnen met één proefteam, de gratis versie en wat tijd. Tijdens de proef zijn feature flags in de productieomgeving ingezet, zijn er resultaten verzameld en vervolgens intern gedeeld. Andere teams hebben zelf om de tool gevraagd, in plaats van dat ze deze van bovenaf opgelegd kregen.
Concreet:
- Flagsmith is geselecteerd op basis van een duidelijke criterialijst: conformiteit met de OpenFeature-standaard (geen vendor lock-in), naadloze integratie met de Java/Angular-stack en de mogelijkheid tot implementatie binnen de OpenShift-omgeving van de klant.
- Een proof of concept in productie op de gratis versie vanaf juli 2022, gevolgd door de enterprise-versie in de OpenShift-omgeving van de klant in januari 2025, zodra er daadwerkelijk vraag naar was.
- SSO via het bestaande Keycloak-systeem, zonder dat er een parallelle identiteit hoeft te worden beheerd.
- Gecentraliseerd beheer: één uniform overzicht van wie wat activeert, voor wie en wanneer.
Code wordt nu continu naar de productieomgeving doorgezet. De activering vindt plaats zodra een functie klaar is voor de gebruikers waarvoor deze bedoeld is, en kan onmiddellijk worden uitgeschakeld als er iets misgaat.
De cijfers
| 88% | ~2 jaar | Implementeren ≠ activeren |
|---|---|---|
| van de teams (15 van de 17) gebruiken feature flags in de productieomgeving. | zodat de invoering zich vanuit één proefteam zou verspreiden, zonder een plan van bovenaf. | Implementatie en activering zijn nu twee afzonderlijke beslissingen. |
Deze cijfers hebben betrekking op een specifiek project in een specifieke context.
Wat maakte het verschil?
Niet de tool zelf, maar de manier waarop die werd geïntroduceerd. We bouwden voort op wat teams al gebruikten: de open standaard, de bestaande stack en de reeds geïmplementeerde Keycloak. Daardoor hoefde niemand iets nieuws te leren en was er geen sprake van de gebruikelijke weerstand. De acceptatie groeide door bewijs: de pilot toonde de waarde aan, waarna de rest vroeg om mee te doen. Het duidelijkste teken is de overstap van de gratis versie naar de betaalde enterprise-versie op de eigen infrastructuur van de klant. Teams betalen niet om een tool te behouden die ze slechts tolereerden.
Daarom spreken we van ‘overgang’ in plaats van ‘transformatie’: een geleidelijke ontwikkeling die verankerd is in de realiteit van elke organisatie, en geen knop die je zomaar omzet. Deze aanpak is geschikt wanneer er al een CI/CD-basis aanwezig is en het management bereid is om de invoering te laten groeien op basis van bewezen resultaten. Als dat niet het geval is, pas je je aan.
Een stap verder gaan
Dit project maakt deel uit van onze ‘IT Mission’-aanpak, naast L4F (analyse en sturing van de applicatieportefeuille via AI) en organisatorische transitie. 5th floor begeleidt sinds 2017 de digitale transformatie van Belgische overheidsinstellingen en is sinds 2025 B Corp-gecertificeerd.
Als je het risico van releases te groot vindt, of als je uit angst om te vroeg iets prijs te geven niet in je ritme komt, neem dan contact met ons op. Een gesprek van een uur is vaak al voldoende om de eerste stappen in kaart te brengen.
