Hotfix az alkalmazásfejlesztésben: lényeg, mechanizmus és alkalmazás

Mi az a hotfix és mikor van rá szükség?

Hotfix (forró javítás) — egy patch az alkalmazás éles verziójához, amely soron kívül kerül kiadásra egy kritikus probléma megoldására. A hotfix órákon belül eljut a felhasználókhoz, nem napokon belül, és kizárólag olyan helyzetekre szolgál, amikor az alkalmazás nem érhető el, adatokat veszít vagy megsérti a felhasználók biztonságát.

Tipikus forgatókönyvek hotfixhez: crash induláskor bizonyos eszközökön (regresszió az utolsó kiadás után), személyes adatok szivárgása hibás engedélyezés miatt, működésképtelen fizetési integráció (bevételkiesés), GDPR/CCPA megfelelőség megsértése. Mindezek a helyzetek P0 vagy P1 severity szintűek az incidens besorolásban. Tervezett feladatok — optimalizálás, refaktorálás, új képernyő — soha nem hotfixen keresztül történnek.

Fontos szabály: a hotfix minimális számú változtatást tartalmaz (1-2 fájl, 10-20 sorkód). Minél kisebb a diff, annál kisebb az új hiba bevezetésének kockázata. Ha a javításhoz architektúraváltoztatásra vagy új modul hozzáadására van szükség — ez nem hotfix, hanem vészhelyzeti kiadás (emergency release), amely teljes code review-t és QA-t igényel.

Miben különbözik a hotfix a szokásos kiadástól

A hotfix és a tervezett kiadás közötti fő különbségek a sebesség, a változtatások mérete és a tesztelés szintje. A tervezett kiadás tucatnyi funkciót tartalmazhat, átmegy a teljes QA cikluson (regression + integration + UI tests) és 1-2 hétig tart a code freeze-től a telepítésig. Hotfix egy-két javítást tartalmaz, gyorsított átnézésen (2 jóváhagyás a 3 helyett) és minimális smoke testen esik át.

A Git folyamat szempontjából a hotfix a kiadási tag-ből készül, nem a develop ágból. Ez garantálja, hogy csak a probléma megoldásához szükséges változtatások kerüljenek a hotfixbe, anélkül, hogy véletlenül befejezetlen funkciók is bekerülnének a develop-ból. Telepítés után a hotfix visszakerül a main és develop ágakba (cherry-pick vagy merge útján).

Tervezett kiadás és hotfix összehasonlítása

Fontos: nem minden sürgős feladat hotfix. Ha a menedzser azt mondja, hogy „sürgősen hozzá kell adni egy gombot” — ez nem hotfix, hanem prioritásváltás. Az igazi hotfixet a felhasználó számára való severity határozza meg, nem az üzlet sürgőssége. Szempont: ha az alkalmazás nem omlik össze és az adatok nem szivárognak — a feladat várhat a tervezett kiadásra.

Hotfix folyamat: észleléstől a telepítésig

Az első lépés egy kritikus probléma észlelése után a triage — a severity gyors felmérése. Az ügyeletes fejlesztő (on-call engineer) megerősíti a hibát, ellenőrzi a logokat és crash reportokat, meghatározza, hogy a probléma az utolsó kiadás regressziója vagy egy régi hiba. Ha a severity P0 — a hotfix pipeline elindul. Triage szakasz nem tarthat tovább 15 perc nél.

Második lépés — ág létrehozása az utolsó kiadási tag-ből (v2.5.0 → hotfix/v2.5.1). A fejlesztő minimális javítást végez, az üzenetben HOTFIX előtaggal commitol, pushol és [HOTFIX] jelöléssel PR-t nyit. Fast-track code review: két reviewert automatikusan kijelöl a CODEOWNERS, a review ideje — legfeljebb 30 perc. Ha 20 percen belül nincs változtatás — a reviewer kihagyásra kerül, a következő kerül kijelölésre.

Harmadik lépés — építés és telepítés CI/CD-n keresztül. A hotfix pipeline eltér a szokásostól: a hosszú integrációs tesztek (órákig tartók) kimaradnak, csak a smoke suite fut (10-15 kritikus forgatókönyv, 5-10 perc). Telepítés utáni megfigyelés: crash rate, error rate, API latency — 30 percig. DORA metrics hotfixekhez: helyreállítási idő (MTTR) kevesebb, mint 1 óra.

# .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

Ebben a pipeline-ban a fő optimalizálások: diff ellenőrzése (legfeljebb 30 sor), integrációs tesztek kihagyása, automatikus telepítés staging és production környezetbe sikeres smoke test esetén. HOTFIX_MODE környezeti változó további ellenőrzéseket aktivál futásidőben — például kiterjesztett naplózást a gyors hibakereséshez.

Hotfix ágak a Git-ben: helyes stratégia

A hotfix ágakkal való munka stratégiáját a Gitflow Workflow írja le. Fő szabály: a hotfix ág az utolsó kiadási tag-ből jön létre (git checkout -b hotfix/v2.5.1 tags/v2.5.0), nem a develop-ból vagy main-ből. Ez garantálja, hogy a hotfix ugyanazon a kódállapoton alapul, amely élesen van, és nem veszi át a befejezetlen változtatásokat a develop-ból.

A javítás befejezése után a hotfix ágat összevonják a main (vagy master) és develop ágakkal. Main-be — szokásos merge commit az új javító kiadás tag-jével (v2.5.1). Develop-be — merge vagy cherry-pick, a csapat politikájától függően. Ha a develop több változtatást tartalmaz, mint a main, akkor a hotfix specifikus commit-jának cherry-pick-je ajánlott a konfliktusok elkerülése érdekében. GitFlow a hotfix először main-be, majd a main-t develop-be történő összevonását ajánlja.

# Hotfix ág létrehozása a legutóbbi kiadási tag-ből
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Javítás alkalmazása
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Összevonás main-be és kiadás tag-elése
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Összevonás develop-ba is
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Ideiglenes ág eltávolítása
git branch -d hotfix/v2.5.1

Fontos: ha a hotfix olyan hibát javít, amely a jelenlegi develop ágban is létezik (a hibát néhány sprinttel korábban vezették be), akkor a hotfix main-be és develop-be történő összevonása után a develop már tartalmazza a javítást. Ha a hibát csak a kiadási ágban vezették be (cherry-pick útján halmozódott fel hiba), akkor a develop-ban lehet, hogy nincs szükség a javításra. Root cause analysis segít meghatározni, hogy szükséges-e a cherry-pick a develop-ban.

A hotfixek kockázatai és hogyan csökkenthetők

A hotfix fő kockázata — új, súlyosabb hiba bevezetése sietség miatt. A Stripe (2021) kutatása szerint a hotfixek 15%-a regressziót okoz és második hotfixet igényel. Ez a gonoszság törvénye: minél gyorsabban javítunk, annál nagyobb a tévedés valószínűsége. Kockázat csökkentése a diff méretének szigorú korlátozásával (legfeljebb 30 sor) és kötelező automatikus smoke testtel érhető el.

Második kockázat — technikai adósság felhalmozódása. Ha a csapat rendszeresen hotfixeket használ tervezett kiadások helyett, a kódbázis leromlik: a hotfix commitek nem esnek át refaktoráláson, az ideiglenes megoldásokat nem váltják fel helyesekkel, a dokumentáció nem frissül. Health check: ha a hotfixek havonta többször jelennek meg — a kiadási folyamatot felül kell vizsgálni.

Harmadik kockázat — pszichológiai. A rendszeres hotfixek kimerítik a csapatot: az on-call fejlesztők állandó stresszben vannak, a code review formalitássá válik (mindenki gyorsan akar), a minőségi kultúra csökken. A hotfixek normális gyakorisága egy érett csapatnál 1-2 negyedévenként. Ha több — a probléma nem a hotfixekben, hanem a tervezett kiadások minőségében van.

Mi a teendő hotfix után

A hotfix telepítése és a metrikák stabilizálódása után post-mortem (hibáztatásmentes retrospektív) következik. A csapat négy kérdésre válaszol: mi történt, miért nem fogták meg az ellenőrzések a hibát, mit tettek a javítás érdekében, hogyan előzhető meg a megismétlődés. A post-mortem a hotfix után 24-48 órán belül történik, amíg a részletek frissek a memóriában. Blameless culture — a fő elv: a folyamatokat vitatjuk meg, nem az embereket.

A post-mortem eredménye — konkrét action item-ek felelősökkel és határidőkkel. Tipikus action item-ek: unit test hozzáadása a kihagyott esetre, smoke test suite bővítése, monitorozás javítása (riasztás hozzáadása egy metrikához), runbook frissítése hasonló incidensekhez. Action item-eket a következő tervezett kiadásig végre kell hajtani.