\u0425\u043E\u0442\u0444\u0438\u043A\u0441 \u0443 \u0440\u0430\u0437\u0432\u043E\u0458\u0443 \u0430\u043F\u043B\u0438\u043A\u0430\u0446\u0438\u0458\u0430: \u0441\u0443\u0448\u0442\u0438\u043D\u0430, \u043C\u0435\u0445\u0430\u043D\u0438\u0437\u0430\u043C \

Ce este hotfix și când este necesar?

Hotfix (corecție la cald) — un patch pentru versiunea de producție a aplicației, lansat în afara rândului pentru a remedia o problemă critică. Hotfix este livrat utilizatorilor în ore, nu zile, și este destinat exclusiv situațiilor când aplicația este indisponibilă, pierde date sau încalcă securitatea utilizatorilor.

Scenarii tipice pentru hotfix: crash la pornire pe anumite dispozitive (regresie după ultima lansare), scurgerea datelor personale din cauza autorizării incorecte, integrare de plată nefuncțională (pierdere de venituri), încălcarea conformității GDPR/CCPA. Toate aceste situații au severity P0 sau P1 în clasificarea incidentelor. Sarcini planificate — optimizare, refactorizare, ecran nou — nu se fac niciodată prin hotfix.

Regulă importantă: hotfix conține un număr minim de modificări (1-2 fișiere, 10-20 de linii de cod). Cu cât diff-ul este mai mic, cu atât riscul de a introduce o nouă eroare este mai scăzut. Dacă pentru remediere este necesară schimbarea arhitecturii sau adăugarea unui modul nou — acesta nu este un hotfix, ci o lansare de urgență care necesită un code review complet și QA.

Cu ce se deosebește hotfix de lansarea obișnuită

Principalele diferențe între hotfix și lansarea planificată sunt viteza, volumul modificărilor și nivelul de testare. Lansarea planificată poate include zeci de funcții, trece prin ciclul complet QA (regression + integration + UI tests) și durează 1-2 săptămâni de la code freeze până la implementare. Hotfix include una-două corecții, trece printr-o revizuire accelerată (2 aprobări în loc de 3) și un smoke test minimal.

Din punctul de vedere al procesului Git, hotfix este creat din tag-ul de lansare, nu din ramura develop. Aceasta garantează că în hotfix vor ajunge doar modificările necesare pentru remedierea problemei, fără a captura accidental caracteristici neterminate din develop. După implementare, hotfix este împins îneapoi în main și develop (prin cherry-pick sau merge).

Comparație între lansarea planificată și hotfix

Important: nu orice sarcină urgentă este un hotfix. Dacă managerul spune «urgent trebuie adăugat un buton» — acesta nu este un hotfix, ci o schimbare de prioritate. Adevăratul hotfix este definit de severitatea pentru utilizator, nu de urgența pentru afacere. Criteriu: dacă aplicația nu crapă și datele nu se scurg — sarcina așteaptă lansarea planificată.

Procesul hotfix: de la detectare la implementare

Primul pas după detectarea problemei critice este triage — evaluarea rapidă a severității. Dezvoltatorul de serviciu (on-call engineer) confirmă eroarea, verifică logurile și rapoartele de crash, determină dacă problema este o regresie a ultimei lansări sau o eroare de lungă durată. Dacă severitatea este P0 — pipeline-ul hotfix este pornit. Etapa de triage nu trebuie să dureze mai mult de 15 minute.

Al doilea pas — crearea ramurii din ultimul tag de lansare (v2.5.0 → hotfix/v2.5.1). Dezvoltatorul aplică o corecție minimă, face commit cu prefixul HOTFIX în mesaj, face push și deschide un PR cu mențiunea [HOTFIX]. Fast-track code review: doi recenzenți sunt atribuiți automat prin CODEOWNERS, timpul de recenzie — nu mai mult de 30 de minute. Dacă nu există modificări timp de 20 de minute — recenzentul este omis, următorul este desemnat.

Al treilea pas — construirea și implementarea prin CI/CD. Pipeline-ul hotfix diferă de cel obișnuit: testele lungi de integrare (care durează ore) sunt omise, se rulează doar smoke suite (10-15 scenarii critice, 5-10 minute). După implementare, monitorizare: crash rate, error rate, API latency — timp de 30 de minute. DORA metrics pentru hotfix-uri: timpul de recuperare (MTTR) trebuie să fie mai mic de 1 oră.

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

În acest pipeline, optimizările cheie: verificarea diff-ului (nu mai mult de 30 de linii), omiterea testelor de integrare, implementarea automată pe staging și production la succesul smoke test-ului. HOTFIX_MODE variabila de mediu activează verificări suplimentare în runtime — de exemplu, logare extinsă pentru diagnosticarea rapidă a problemelor.

Ramurile hotfix în Git: strategia corectă

Strategia de lucru cu ramurile hotfix este descrisă în Gitflow Workflow. Regula principală: ramura hotfix este creată din ultimul tag de lansare (git checkout -b hotfix/v2.5.1 tags/v2.5.0), nu din develop sau main. Aceasta garantează că hotfix-ul se bazează pe aceeași stare a codului care este acum în producție și nu captează modificări neterminate din develop.

După finalizarea corecției, ramura hotfix este împinsă în main (sau master) și develop. În main — un commit obișnuit de merge cu tag-ul noii lansări de corecție (v2.5.1). În develop — merge sau cherry-pick, în funcție de politica echipei. Dacă develop conține mai multe modificări decât main, se recomandă cherry-pick-ul commit-ului specific al hotfix-ului pentru a evita conflictele. GitFlow recomandă împingerea hotfix în main întâi, iar apoi a main în develop.

# \u041A\u0440\u0435\u0438\u0440\u0430\u0458 hotfix \u0433\u0440\u0430\u043D\u0443 \u043E\u0434 \u043F\u043E\u0441\u043B\u0435\u045B\u0435\u0433 \u0440\u0435\u043B\u0438\u0437\u043D\u043E\u0433 \u0442\u0430\u0433\u0430
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# \u041F\u0440\u0438\u043C\u0435\u043D\u0438 \u043F\u043E\u043F\u0440\u0430\u0432\u043A\u0443
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# \u0421\u043F\u043E\u0458\u0438 \u0441\u0430 main \u0438 \u043E\u0437\u043D\u0430\u0447\u0438 \u0438\u0437\u0434\u0430\u045A\u0435 \u0442\u0430\u0433\u043E\u043C
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# \u0422\u0430\u043A\u043E\u0452\u0435 \u0441\u043F\u043E\u0458\u0438 \u0441\u0430 develop
git checkout develop
git merge --no-ff hotfix/v2.5.1

# \u041E\u0431\u0440\u0438\u0448\u0438 \u043F\u0440\u0438\u0432\u0440\u0435\u043C\u0435\u043D\u0443 \u0433\u0440\u0430\u043D\u0443
git branch -d hotfix/v2.5.1

Important: dacă hotfix-ul corectează o eroare existentă în ramura develop curentă (eroarea a fost introdusă acum câteva sprinturi), atunci după împingerea hotfix în main și develop, develop conține deja corecția. Dacă eroarea a fost introdusă doar în ramura de lansare (prin cherry-pick s-a acumulat o eroare), atunci în develop corecția poate să nu fie necesară. Root cause analysis ajută să se determine dacă cherry-pick-ul în develop este necesar.

Riscurile hotfix-urilor și cum să le minimizați

Principalul risc al hotfix-ului — introducerea unei noi erori, mai grave, din cauza grabei. Conform cercetării Stripe (2021), 15% dintre hotfix-uri cauzează regresie și necesită un al doilea hotfix. Aceasta este legea răutății: cu cât corectăm mai repede, cu atât probabilitatea de a greși este mai mare. Minimizarea riscului se realizează prin limitarea strictă a dimensiunii diff-ului (nu mai mult de 30 de linii) și un smoke test automat obligatoriu.

Al doilea risc — acumularea datoriei tehnice. Dacă echipa folosește regulat hotfix-uri în loc de lansări planificate, baza de cod degradează: commit-urile hotfix nu trec prin refactorizare, soluțiile temporare nu sunt înlocuite cu cele corecte, documentația nu este actualizată. Health check: dacă hotfix-urile sunt lansate mai des de o dată pe lună — procesul de lansare necesită revizuire.

Al treilea risc — psihologic. Hotfix-urile regulate epuizează echipa: dezvoltatorii on-call sunt în stres constant, code review-ul devine o formalitate (toți vor să termine mai repede), cultura calității scade. Frecvența normală a hotfix-urilor pentru o echipă matură este de 1-2 pe trimestru. Dacă este mai mult — problema nu este în hotfix-uri, ci în calitatea lansărilor planificate.

Ce să faceți după hotfix

După implementarea hotfix-ului și stabilizarea metricilor, se efectuează un post-mortem (restrospectivă fără vinovăție). Echipa răspunde la patru întrebări: ce s-a întâmplat, de ce verificările nu au detectat eroarea, ce s-a făcut pentru remediere, cum să previnăm repetarea. Post-mortem-ul se efectuează în 24-48 de ore după hotfix, când detaliile sunt încă proaspete în memorie. Blameless culture — principiul cheie: se discută procesele, nu oamenii.

Rezultatul post-mortem-ului — action items concrete cu persoane responsabile și termene. Action items tipice: adăugarea unui test unitar pentru cazul care a fost omis, extinderea setului de smoke test, îmbunătățirea monitorizării (adăugarea unei alerte pentru o metrică), actualizarea runbook-ului pentru incidente similare. Action items trebuie să fie executate până la următoarea lansare planificată.