Het is één grote wildgroei geworden en dat is niet gek

Vier developmentomgevingen, en geen twee draaien dezelfde software. De ene omgeving draait versie 1 van de frontend, de andere versie 2. Een update werkt op de ene plek wel en op de andere niet, en niemand weet nog precies wat er waar staat. Onze collega Tom Brouwer trof het aan bij een groot internationaal accountantskantoor, waar hij meebouwt aan een intern ontwikkelplatform.

"Het is één groot rotzooitje geworden. En op zich niet heel gek: op het moment dat je begint en je snel klaar wil zijn, kan je het op zo'n manier doen. Zonder erover na te denken."

Hoe wildgroei ontstaat

Het idee achter het platform is sterk. Accountants met programmeerkennis bouwen kleine tools, bijvoorbeeld in Python. Het platform regelt authenticatie, autorisatie, deployment en de koppelingen met externe API's, zodat niet elke tool zijn eigen infrastructuur nodig heeft. Maar het platform zelf bestond uit losse microservices, elk met een eigen repository, en per omgeving een aparte deploydefinitie. Zeven repositories waarin je versienummers handmatig bijwerkt. Zie je er één over het hoofd, dan loopt acceptatie uit de pas met productie.

Volgens Tom is dat geen uitzondering: "veel bedrijven denken bij de start niet na over hun deployproces. De applicatie en het gebruik groeien door, terwijl de infrastructuur eronder 'nog een soort proof-of-concept-achtig idee' blijft." 

Eén weg van deployen

De oplossing die Tom en zijn team bouwen: één helm chart die het complete platform in één keer deployt. Eén Git-repository als basis met de juiste applicatieversies; per omgeving overschrijf je alleen de variabelen. Kant-en-klare GitOps-tooling zoals Flux helpt ook bij het inrichten van de infrastructuur.

Feature-omgevingen zijn niet langer statisch. Je geeft een naam op en het platform zet een complete omgeving voor je neer — en haalt hem daarna weer weg. Dat scheelt in de cloudkosten, want er draaien geen omgevingen dag en nacht die niemand gebruikt. Pipelines voeren de kwaliteits- en securitychecks automatisch uit.

"Stel dat er morgen iets uitvalt, dan moeten we het binnen tien minuten weer up-and-running hebben. Dan hoeven we niet per service of per repo te gaan kijken, maar updaten we nog maar op één plek."

De ambitie: elke dag naar productie

Hoe groot de stap is, blijkt uit het huidige tempo. "Nu deployen we één keer in de maand of zo. Of één keer in de twee maanden als we mazzel hebben." Releases naar buitenlandse partnerorganisaties gaan zelfs nog handmatig, soms op zaterdag — met alle spanning van dien.

Tom kijkt verder vooruit: "Ik zou het het mooiste vinden als we over twee jaar gewoon dagelijks vijf deployments naar productie kunnen doen." Hij nuanceert het zelf meteen: dat is ambitieus, laat het er eerst maar één per dag zijn. Maar de richting is helder. Je bouwt functionaliteit, of laat AI die bouwen, en die gaat door de pipelines heen. Een developer kijkt er nog even naar, en dan staat het op productie. Zoals agile werken ooit bedoeld is.

Van wildgroei naar in control: hoe Openpeople dat aanpakt

We weten uit ervaring dat het lastig is om vanuit de situatie zelf te zien waar de grootste pijn zit. Je zit er middenin. Alles voelt urgent. En het is verleidelijk om te blijven doorwerken aan features in plaats van aan de infrastructuur daaromheen.

Daarom werken we in drie stappen:

Stap 1 — Quickscan

In één sessie brengen we je huidige situatie in kaart. Hoe ziet je deployment-proces er nu uit? Waar zitten de handmatige stappen? Wat kost het je — in tijd, in risico, in frustratie? We kijken naar je omgevingen, je pipelines, je cloudgebruik. Geen weken inventarisatie, maar een gerichte analyse die snel de kern blootlegt: waar zit de pijn, wat is de snelste winst?

Stap 2 — Verbeterplan op maat

Geen generiek advies, geen PowerPoint met best practices die je zelf nog moet vertalen. Op basis van de quickscan maken we een concreet stappenplan: welke aanpak, in welke volgorde, passend bij jouw team, jouw stack en jouw organisatie. Inclusief een realistisch beeld van wat het kost en wat het oplevert.

Stap 3 — Gestructureerde uitvoering

Onze engineers werken samen met jouw team. Niet als externe partij die iets neerzet en vertrekt, maar als mensen die kennis overdragen en structureel bouwen aan iets wat blijft. Van wildgroei naar één gestroomlijnde deployment-straat — meetbaar en controleerbaar.

Wij werken met engineers die dit soort trajecten kennen — niet theoretisch, maar uit de praktijk. Als je herkent wat hier staat, is de quickscan de logische eerste stap. Binnen één gesprek weet je waar je staat en wat er nodig is om verder te komen.