Hotfix in app ontwikkeling: essentie, mechanisme en toepassing

Wat is een hotfix en wanneer is het nodig?

Hotfix Hotfix (hete correctie) — een patch voor de productieversie van de applicatie, buiten de volgorde om uitgebracht om een kritiek probleem op te lossen. Hotfix wordt binnen uren aan gebruikers geleverd, niet dagen, en is uitsluitend bedoeld voor situaties waarin de applicatie niet beschikbaar is, gegevens verliest of de veiligheid van gebruikers schendt.

Typische scenario’s voor hotfix: crash bij het opstarten op bepaalde apparaten (regressie na de laatste release), lekkage van persoonsgegevens door onjuiste autorisatie, niet-werkende betalingsintegratie (inkomstenverlies), schending van GDPR/CCPA-naleving. Al deze situaties hebben severity P0 of P1 in de incidentclassificatie. Geplande taken — optimalisatie, refactoring, nieuw scherm — worden nooit via hotfix gedaan.

Belangrijke regel: een hotfix bevat een minimaal aantal wijzigingen (1-2 bestanden, 10-20 regels code). Hoe kleiner de diff, hoe lager het risico op het introduceren van een nieuwe fout. Als voor de correctie een architectuurwijziging of toevoeging van een nieuwe module nodig is — dan is dit geen hotfix, maar een emergency release die volledige code review en QA vereist.

Hoe verschilt een hotfix van een gewone release

De belangrijkste verschillen tussen hotfix en geplande release zijn snelheid, omvang van wijzigingen en testniveau. Een geplande release kan tientallen functies omvatten, de volledige QA-cyclus doorlopen (regression + integration + UI tests) en 1-2 weken duren van code freeze tot implementatie. Hotfix bevat een of twee correcties, doorloopt een versnelde beoordeling (2 goedkeuringen in plaats van 3) en een minimale smoke test.

Vanuit het oogpunt van het Git-proces wordt hotfix gemaakt vanaf de release-tag, niet vanaf de develop-tak. Dit garandeert dat alleen de wijzigingen die nodig zijn om het probleem op te lossen in de hotfix terechtkomen, zonder onbedoeld onvoltooide functies uit develop mee te nemen. Na implementatie wordt hotfix teruggezet naar main en develop (via cherry-pick of merge).

Vergelijking van geplande release en hotfix

Belangrijk: niet elke dringende taak is een hotfix. Als de manager zegt "dringend moet er een knop worden toegevoegd" — dan is dit geen hotfix, maar een prioriteitsverschuiving. Een echte hotfix wordt bepaald door de severity voor de gebruiker, niet door de urgentie voor het bedrijf. Criterium: als de applicatie niet crasht en gegevens niet lekken — wacht de taak op de geplande release.

Hotfix-proces: van detectie tot implementatie

De eerste stap na het detecteren van een kritiek probleem is triage — snelle beoordeling van de severity. De dienstdoende ontwikkelaar (on-call engineer) bevestigt de fout, controleert logs en crashrapporten, bepaalt of het probleem een regressie is van de laatste release of een langdurige fout. Als severity P0 is — wordt de hotfix-pipeline gestart. Triage-fase mag niet langer duren dan 15 minuten.

Tweede stap — aanmaken van een tak vanaf de laatste release-tag (v2.5.0 → hotfix/v2.5.1). De ontwikkelaar past een minimale correctie toe, committed met het voorvoegsel HOTFIX in het bericht, pusht en opent een PR met de aanduiding [HOTFIX]. Fast-track code review: twee reviewers worden automatisch toegewezen via CODEOWNERS, de beoordelingstijd — niet meer dan 30 minuten. Als er binnen 20 minuten geen wijzigingen zijn — wordt de reviewer overgeslagen en wordt de volgende aangewezen.

Derde stap — bouwen en implementeren via CI/CD. De hotfix-pipeline verschilt van de gewone: lange integratietests (die uren duren) worden overgeslagen, alleen de smoke suite wordt uitgevoerd (10-15 kritieke scenario’s, 5-10 minuten). Na implementatie monitoring: crash rate, error rate, API latency — gedurende 30 minuten. DORA metrics voor hotfixes: hersteltijd (MTTR) moet minder dan 1 uur zijn.

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

In deze pipeline zijn de belangrijkste optimalisaties: controle van de diff (niet meer dan 30 regels), overslaan van integratietests, automatische implementatie op staging en production bij succesvolle smoke test. HOTFIX_MODE omgevingsvariabele activeert extra controles in runtime — bijvoorbeeld uitgebreide logging voor snelle diagnostiek van problemen.

Hotfix-takken in Git: de juiste strategie

De strategie voor het werken met hotfix-takken wordt beschreven in Gitflow Workflow. De hoofdregel: een hotfix-tak wordt gemaakt vanaf de laatste release-tag (git checkout -b hotfix/v2.5.1 tags/v2.5.0), niet vanaf develop of main. Dit garandeert dat de hotfix is gebaseerd op dezelfde codestatus die momenteel in productie is en geen onvoltooide wijzigingen uit develop meeneemt.

Na het voltooien van de correctie wordt de hotfix-tak samengevoegd met main (of master) en develop. Naar main — een normale merge commit met de tag van de nieuwe correctierelease (v2.5.1). Naar develop — merge of cherry-pick, afhankelijk van het teambeleid. Als develop meer wijzigingen bevat dan main, wordt cherry-pick van de specifieke hotfix-commit aanbevolen om conflicten te voorkomen. GitFlow beveelt aan om hotfix eerst naar main te mergen en vervolgens main naar develop.

# Maak een hotfix-tak aan vanaf de laatste release-tag
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Pas de correctie toe
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Voeg samen met main en tag de release
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Voeg ook samen met develop
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Verwijder de tijdelijke tak
git branch -d hotfix/v2.5.1

Belangrijk: als de hotfix een fout corrigeert die in de huidige develop-tak bestaat (de fout is enkele sprints geleden geïntroduceerd), dan bevat develop na het mergen van hotfix naar main en develop al de correctie. Als de fout alleen in de release-tak is geïntroduceerd (via cherry-pick is een fout opgestapeld), dan is de correctie in develop mogelijk niet nodig. Root cause analysis helpt bepalen of cherry-pick in develop nodig is.

Risico’s van hotfixes en hoe deze te minimaliseren

Het belangrijkste risico van een hotfix — het introduceren van een nieuwe, ernstigere fout door haast. Volgens onderzoek van Stripe (2021) veroorzaakt 15% van de hotfixes regressie en vereist een tweede hotfix. Dit is de wet van de weerzinwekkendheid: hoe sneller we corrigeren, hoe groter de kans op een fout. Risicominimalisatie wordt bereikt door strikte beperking van de diff-grootte (niet meer dan 30 regels) en een verplichte automatische smoke test.

Tweede risico — ophoping van technische schuld. Als het team regelmatig hotfixes gebruikt in plaats van geplande releases, degradeert de codebase: hotfix-commits ondergaan geen refactoring, tijdelijke oplossingen worden niet vervangen door correcte, documentatie wordt niet bijgewerkt. Health check: als hotfixes vaker dan een keer per maand worden uitgebracht — moet het releaseproces worden herzien.

Derde risico — psychologisch. Regelmatige hotfixes putten het team uit: on-call ontwikkelaars staan onder constante stress, code review wordt een formaliteit (iedereen wil snel), de kwaliteitscultuur daalt. Normale frequentie van hotfixes voor een volwassen team is 1-2 per kwartaal. Als het meer is — ligt het probleem niet bij de hotfixes, maar bij de kwaliteit van de geplande releases.

Wat te doen na een hotfix

Na implementatie van de hotfix en stabilisatie van meetgegevens wordt een post-mortem (blameless retrospective) uitgevoerd. Het team beantwoordt vier vragen: wat er is gebeurd, waarom de controles de fout niet hebben opgemerkt, wat er is gedaan om te corrigeren, hoe herhaling te voorkomen. Post-mortem wordt binnen 24-48 uur na de hotfix uitgevoerd, zolang de details nog vers in het geheugen zijn. Blameless culture — het belangrijkste principe: processen worden besproken, niet mensen.

Het resultaat van post-mortem — concrete action items met verantwoordelijke personen en deadlines. Typische action items: het toevoegen van een unit test voor het geval dat over het hoofd is gezien, het uitbreiden van de smoke test suite, het verbeteren van de monitoring (toevoegen van een alert voor een metriek), het bijwerken van de runbook voor soortgelijke incidenten. Action items moeten vóór de volgende geplande release worden uitgevoerd.