Feature freeze en code freeze in app-ontwikkeling: essentie, verschillen en werking

Wat is een feature freeze?

Feature freeze is een tijdelijk verbod op het toevoegen van nieuwe functionaliteit aan de codebase, ingesteld voor een geplande release. Het team stopt met het mergen van features en schakelt over op het oplossen van bugs, optimalisatie en het oppoetsen van bestaande code. Ontwikkelaars voltooien onafgemaakte features alleen binnen het kader van bugfixes, zonder de scope uit te breiden.

Feature freeze lost het probleem op van onafgemaakte features (work-in-progress) die niet op tijd klaar zijn voor de release maar al gedeeltelijk in de hoofdtak zijn gemerged. Als nieuwe features blijven worden toegevoegd, neemt het risico op regressie toe: elke nieuwe integratie vereist hertesten van reeds voltooide modules. Feature freeze legt de release-scope vast en verandert deze van een bewegend doelwit in een stabiele set functionaliteiten.

Belangrijke opmerking: feature freeze ≠ code freeze. Bij feature freeze zijn bugfixes, refactoring, het bijwerken van afhankelijkheden en documentatie toegestaan. Alleen nieuwe user-facing features zijn verboden, dus alle code die het gedrag van de app vanuit gebruikersperspectief verandert. Controle bij code review: als een PR een nieuw scherm, knop of API-methode toevoegt, wordt deze afgewezen tot de freeze wordt opgeheven.

Wat is een code freeze en hoe verschilt het van feature freeze

Code freeze is een strengere praktijk waarbij alle codewijzigingen volledig zijn verboden. Zelfs bugfixes zijn niet toegestaan tenzij ze kritiek zijn. Code freeze wordt voor een korte periode (meestal 24-48 uur) ingesteld en garandeert dat de release-build is samengesteld uit een vaste set commits.

Het verschil tussen feature freeze en code freeze zit in het controleniveau. Feature freeze beheert de scope: wat er precies in de release komt. Code freeze beheert de kwaliteit: het risico op het introduceren van een nieuwe bug een dag voor de release wordt uitgesloten. In de praktijk gebruiken veel teams een tweetrapsmodel: 1-2 weken voor de release — feature freeze, 24-48 uur — code freeze. Code freeze is vooral belangrijk voor mobiele apps, waarbij de build enkele dagen voor de geplande releasedatum in de winkel moet worden geüpload.

Uitzondering op code freeze — beveiligingsfixes voor kritieke kwetsbaarheden (CVE met score 9+). Dergelijke wijzigingen doorlopen een noodproces met versnelde code review en teamnotificatie. Alle andere wijzigingen worden uitgesteld tot de volgende releasecyclus.

Feature freeze vs code freeze: vergelijking

De keuze tussen feature freeze en code freeze hangt af van de volwassenheid van het team en de releasefrequentie. Teams met CI/CD en feature flags kunnen zich beperken tot alleen een code freeze van 24 uur, terwijl teams met maandelijkse releases vaak beide freezes achtereenvolgens gebruiken.

Soorten freezes: volledig, gedeeltelijk en BAU-freeze

Naast de volledige feature freeze en code freeze bestaan er flexibelere varianten. Partial feature freeze (gedeeltelijke freeze) blokkeert nieuwe functionaliteit alleen in bepaalde modules — bijvoorbeeld in de betalingsmodule of de authenticatiemodule, terwijl andere componenten open blijven voor wijzigingen.

BAU-freeze (business as usual freeze) is een compromisvariant waarbij alleen grote features met een wijzigingsomvang boven een bepaalde drempel (bijv. 500 regels code) zijn verboden. Kleine verbeteringen, UI-tweaks en bugfixes kunnen nog worden gemerged. BAU-freeze is handig voor projecten met continuous delivery, waarbij een volledige ontwikkelingsstop van een week economisch ongunstig is.

Er bestaat ook het concept deployment freeze — een volledige stop van deploys naar productie, kenmerkend voor het vakantieseizoen (kerstvakantie, Black Friday). In deze periode worden zelfs hotfixes geblokkeerd als ze geen betrekking hebben op beveiliging. Deployment freeze duurt meestal 1-2 weken en wordt op bedrijfsniveau afgestemd.

Wanneer een freeze invoeren en hoe lang deze duurt

Het optimale moment om een feature freeze in te voeren — na code complete, wanneer alle geplande features zijn gemerged en door QA gaan. De exacte termijn hangt af van de releasecyclus: voor een sprint van twee weken wordt feature freeze 3-4 dagen voor de releasedatum ingesteld, voor een maandelijkse release — 7-10 dagen van tevoren. Code freeze wordt 24-48 uur voor de geplande tijd van de release-build ingesteld.

De duur van de freeze moet minimaal voldoende zijn om de code te stabiliseren. Een te lange freeze (meer dan 2 weken) demotiveert het team en zorgt voor een opeenhoping van niet-gemergede features, die elk na het opheffen van de freeze het risico op conflicten vergroten. Een te korte freeze (minder dan 24 uur voor feature freeze) geeft niet genoeg tijd voor grondig testen en fixes.

Aanbevolen praktijk — de freeze niet instellen op basis van een kalenderdatum, maar op basis van de toestand van de codebase. Feature freeze wordt ingesteld wanneer het aantal open bugs voor de release een drempel overschrijdt (bijv. 10 kritieke bugs). Code freeze — wanneer de build met succes smoke tests en regression suite doorstaat. Time-based freeze (vaste datum) blijft de standaard voor gereguleerde industrieën (fintech, medtech), waar de releasedatum door de toezichthouder is goedgekeurd.

Automatisering van freezes via CI/CD en Git

Handmatige controle van freezes is een bron van fouten: een ontwikkelaar kan per ongeluk een PR mergen die op het opheffen van de freeze moet wachten. Automatisering lost dit probleem op via Git branch protection-regels en CI/CD-pipelines. In de Git-provider (GitHub, GitLab, Bitbucket) worden regels ingesteld die merges naar de releasetak blokkeren zonder speciale tag of goedkeuring van de release manager.

CI/CD-pipeline controleert de status van de freeze voor het bouwen van de build. In Jenkins, GitLab CI of GitHub Actions wordt een stap toegevoegd die het configuratiebestand met het freezerooster leest en builds afwijst als de huidige datum binnen de freeze-periode valt. Alternatief — een feature flag in de admin-panel die deploy naar productie blokkeert.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is actief. PR geblokkeerd." && exit 1

Het voorbeeldscript freeze-check.js leest JSON met het freezerooster uit de root van de repository. Als de huidige datum binnen het interval tussen start_date en end_date voor de opgegeven tak valt — faalt de pipeline met een bericht over de freezestatus. Git branch protection voegt een tweede barrière toe: zelfs als de pipeline niet werkt, staat de regel niet toe een PR zonder goedkeuring te mergen.

Veelgemaakte fouten bij het implementeren van freezes

De eerste fout — een freeze zonder duidelijke opheffingscriteria. Het team bevriest de code maar bepaalt niet welke voorwaarden moeten worden vervuld voor het ontdooien: zero critical bugs, geslaagde regression suite, goedkeuring van de productmanager. Zonder criteria kan een freeze weken duren. Definition of done voor de freeze moet worden gedocumenteerd en bekend zijn bij elke ontwikkelaar.

De tweede fout — te veel uitzonderingen op de freeze. Elke exception ("deze PR is geen feature, maar technische schuld") vervaagt de grens van de freeze. Als exceptions meer dan 20% van de normale PR-stroom bedragen — werkt de freeze niet. Het team hernoemt eenvoudigweg features naar bugfixes om de blokkade te omzeilen.

De derde fout — het negeren van release candidates. Als het team geen release candidate-builds maakt en onmiddellijk na code freeze naar productie deployt, gaat het nut van de freeze verloren: bugs worden ontdekt door gebruikers. Release candidate moet voor code freeze worden gebouwd, getest door QA en op staging, en pas na kwaliteitsbevestiging wordt code freeze ingesteld.

De vierde fout — menselijke factor bij handmatige controle. Een ontwikkelaar kan vergeten de freezestatus te controleren voor het mergen, een release manager kan een melding missen. De enige betrouwbare oplossing — automatische blokkering op het niveau van de Git-provider of CI/CD, die menselijke fouten uitsluit.