Wat als een applicatie zó succesvol is dat hij zijn eigen groei niet kan bijhouden?
Een stabiele en betrouwbare bedrijfskritische applicatie is essentieel voor organisaties. Het zorgt voor continuïteit, zekerheid en een efficiënte bedrijfsvoering. Maar wat gebeurt er als het succes van de applicatie zo groot is dat hij de snelle groei van gebruikers en nieuwe functionaliteiten niet altijd aankan? Downtime leidt bij de gebruiker niet alleen tot frustratie, maar ook tot een verlies van vertrouwen in de betrouwbaarheid van de applicatie.
Het MIXIT-team van AkzoNobel zag dat het tijd was om de applicatie niet alleen te verbeteren, maar ook toekomstbestendig te maken. Om verdere performance-issues te voorkomen en sneller te kunnen reageren op mogelijke storingen, was een fundamentele verandering in de ontwikkel- en releaseprocessen noodzakelijk.
In dit artikel leg ik uit hoe het MIXIT-team deze transitie heeft gerealiseerd en welke concrete voordelen dit opleverde voor zowel de applicatie als haar gebruikers. Daarnaast worden de belangrijkste lessen en voordelen van deze werkwijze uiteengezet.
De oplossing: Trunk-based development
Het MIXIT-team van AkzoNobel stond voor de uitdaging om drie meetbare uitkomsten te realiseren:
- Minder downtime.
- Sneller herstel van downtime.
- Minder impact van downtime op klanten.
Trunk-based development is een bewezen strategie voor softwarelevering, waarbij de nadruk wordt gelegd op continue integratie en gestroomlijnde workflows. Deze aanpak maakt het mogelijk om een meer betrouwbare, cloudgebaseerde oplossing te bieden voor kleurherkenning in de autoreparatiesector.
Uitgangssituatie en uitdagingen
Voor de implementatie van trunk-based development stond het MIXIT-team voor diverse technische en organisatorische uitdagingen:
- Big bang releases: Updates werden eens in de drie weken in één grote release doorgevoerd, wat resulteerde in:
- Moeizame foutopsporing door onderlinge afhankelijkheden tussen wijzigingen.
- Risicovolle rollbacks die meerdere componenten konden beïnvloeden.
- Verhoogde druk op het team tijdens releases en langere hersteltijden bij problemen.
- Component afhankelijkheden
- Conflicten tussen frontend- en backend-componenten veroorzaakten integratieproblemen, wat leidde tot bugs en instabiliteit in de applicatie.
- De noodzaak om verschillende componenten gelijktijdig te releasen bemoeilijkte een snelle en flexibele uitrol van nieuwe functies.
- Tijd naar markt
- Door het batchgewijs releasen van wijzigingen duurde het gemiddeld vijf weken voordat nieuwe functionaliteit en bugfixes bij klanten kwamen.
- In een competitieve markt was deze snelheid onvoldoende om aan de verwachtingen van gebruikers te voldoen.
Om deze uitdagingen aan te pakken, heeft het MIXIT-team gekozen voor de implementatie van trunk-based development, een aanpak die continue integratie en gestroomlijnde deployments faciliteert. In de volgende sectie wordt toegelicht hoe deze transitie is gerealiseerd en welke voordelen dit heeft opgeleverd.
Trunk-based development als oplossing
Trunk-based development houdt in dat de ontwikkelaars werken op één hoofdbranch (de trunk). De belangrijkste kenmerken van deze aanpak zijn:
- Scheiding van deployment en release: Deployments worden uitgevoerd naar datacenters zonder dat de wijzigingen direct zichtbaar zijn voor gebruikers. Releases worden geactiveerd via feature flags, waardoor gecontroleerde uitrol mogelijk is.
- Vereenvoudigd branching model:
- De overstap van Git Flow naar trunk-based development elimineert overbodige branches en minimaliseert integratieproblemen.
- Alle wijzigingen werden direct in de hoofd branche geïntegreerd, wat automatische deployments triggerde.
- Beheerde deployment wachtrij: Een deployment wachtrij zorgde voor sequentiële verwerking, waardoor potentiële problemen werden geïsoleerd en de orde werd gehandhaafd.
- Geavanceerde teststrategieën: Het gebruik van integratietesten, contracttesten en rooktesten verhoogt het vertrouwen in frequente releases.
- API-First ontwikkeling en TypeSpec: Een essentieel onderdeel van het succes was de overstap naar een API-first aanpak. Het team maakte gebruik van TypeSpec om API-contracten te definiëren, die vervolgens automatisch OpenAPI-documentatie genereerden en consistentie tussen services waarborgden.
- API-first: De API wordt ontworpen voordat de implementatie begint. Dit voorkomt onduidelijkheden en zorgt voor een solide basis voor alle services die met de API interageren.
- Gebruik van TypeSpec: Met TypeSpec definieerde het team contracten voor elke API. Deze contracten specificeerden exact welke endpoints beschikbaar waren, welke datatypes werden gebruikt, en welke antwoorden verwacht konden worden.
TypeSpec genereerde automatisch OpenAPI-documentatie, waardoor ontwikkelaars en stakeholders een duidelijke en uniforme bron van waarheid hadden.
- Gebruik van TypeSpec: Met TypeSpec definieerde het team contracten voor elke API. Deze contracten specificeerden exact welke endpoints beschikbaar waren, welke datatypes werden gebruikt, en welke antwoorden verwacht konden worden.
- API-first: De API wordt ontworpen voordat de implementatie begint. Dit voorkomt onduidelijkheden en zorgt voor een solide basis voor alle services die met de API interageren.
TypeSpec voorbeeld:
-
- Voordelen:
- Consistentie: Alle teams werkten met dezelfde contracten, wat integratieproblemen verminderde.
- Betere samenwerking: Zowel ontwikkelaars als niet-technische stakeholders hadden toegang tot leesbare documentatie.
- Efficiëntie: Automatische generatie van documentatie en code zorgde voor een kortere ontwikkelcyclus.
- Nadelen van API-first ontwikkeling:
- Hogere initiële investering: Het ontwerpen van API’s voordat andere componenten worden ontwikkeld kan meer tijd kosten in de beginfase.
- Vereist strikte discipline: Het team moeten zich strikt houden aan de vastgestelde API-contracten om consistentie te waarborgen.
- Voordelen:
- Vergelijking van ontwikkeltijden: De overstap van traditionele naar trunk-based development heeft de doorlooptijd aanzienlijk verbeterd. Onderstaand diagram toont de verschillen in tijd:
Belangrijke succesfactoren
Om trunk-based development effectief te implementeren, heeft het MIXIT-team vier kritieke vereisten geformuleerd:
-
-
- Onafhankelijke code repository: Door over te stappen van een monorepo naar individuele repositories voor elke microservice werden builds en testen eenvoudiger, de complexiteit verminderd en de feedbackloops versneld.
- API-contracten: Met een design-first benadering en gebruik van TypeSpec zorgde het team voor robuuste, duidelijke API-contracten. Deze contracten werden de “single source of truth”, wat inconsistenties minimaliseerde en communicatieproblemen tussen services voorkwam.
- Geleidelijke rollouts: Het adopteren van een gefaseerde deploymentstrategie (bijv. interne tests, regionale releases) maakte gecontroleerd risicobeheer mogelijk. Zo richtten ze zich bijvoorbeeld eerst op Europa, het Midden-Oosten en Afrika (EMA) voordat ze wereldwijd uitrolden.
-
- Realtime monitoring en communicatie: Een deployment dashboard en waarschuwingssystemen maakten realtime tracking en snelle reacties op problemen mogelijk. De vermelding van lopende deployments tijdens de dagelijkse scrum besprekingen zorgden voor transparantie en team uitlijning.
Gerealiseerde voordelen
- Snellere tijd naar markt: Deploymentcycli worden teruggebracht van weken naar uren, waardoor functies en fixes sneller werden geleverd.
- Verbeterde kwaliteit en vertrouwen: Frequentere, kleinere releases maken foutopsporing eenvoudiger en verminderen risico’s.
- Efficiëntie en productiviteit: Door automatisering kan de releasemanager zich richten op strategische taken.
- Heldere documentatie: API-contracten en automatische documentatie zorgen voor een uniforme bron van waarheid.
Uitdagingen en geleerde lessen
Tijdens de transitie naar trunk-based development kwam het team enkele uitdagingen tegen, zoals:
- Complexiteit bij simultane veranderingen: Het gelijktijdig doorvoeren van aanpassingen in de ontwikkelmethodiek, het moderniseren van de applicatie(s), en het herzien van teststrategieën en -procedures is veelomvattend. De belangrijkste les is om veranderingen stapsgewijs door te voeren.
- Test automatisering: Handmatige testen bleken onvoldoende om het tempo van frequente releases te ondersteunen. Geautomatiseerde teststrategieën worden essentieel.
- Consistentie van legacy API’s: De balans tussen onderhoud van bestaande API’s en ontwikkeling van nieuwe functies vergt pragmatisch handelen en heldere communicatie.
Volgende stap
De volgende stap is de implementatie van een gefaseerde release-strategie. Door de nieuwe functionaliteit eerst uit te rollen naar een geselecteerde groep gebruikers, kunnen potentiële problemen vroegtijdig worden geïdentificeerd en opgelost. Dit minimaliseert de impact, aangezien de overige gebruikers blijven werken met de huidige stabiele versie van de software.
Conclusie
De succesvolle implementatie van trunk-based development door het MIXIT-team toont de voordelen van moderne ontwikkelstrategieën. Het proces verbetert efficiëntie, verhoogt betrouwbaarheid en versnelt de tijd naar de markt. Organisaties die een vergelijkbare transitie overwegen, kunnen leren van het belang van stapsgewijze implementatie, robuuste testautomatisering en een sterke focus op samenwerking en communicatie.