Hotfix w tworzeniu aplikacji: istota, mechanizm i jak stosować

Czym jest hotfix i kiedy jest potrzebny?

Hotfix (gorąca poprawka) — to łatka dla wersji produkcyjnej aplikacji, wydawana poza kolejnością w celu usunięcia krytycznego problemu. Hotfix jest dostarczany użytkownikom w ciągu godzin, a nie dni, i przeznaczony wyłącznie do sytuacji, gdy aplikacja jest niedostępna, traci dane lub narusza bezpieczeństwo użytkowników.

Typowe scenariusze dla hotfixa: crash przy uruchomieniu na określonych urządzeniach (regresja po ostatnim wydaniu), wyciek danych osobowych z powodu nieprawidłowej autoryzacji, niedziałająca integracja płatności (utrata revenue), naruszenie GDPR/CCPA compliance. Wszystkie te sytuacje mają severity P0 lub P1 w klasyfikacji incydentów. Zadania planowe — optymalizacja, refaktoryzacja, nowy ekran — nigdy nie są robione przez hotfix.

Ważna zasada: hotfix zawiera minimalną liczbę zmian (1-2 pliki, 10-20 linii kodu). Im mniejszy diff, tym niższe ryzyko wprowadzenia nowego błędu. Jeśli do naprawy wymagana jest zmiana architektury lub dodanie nowego modułu — to nie jest hotfix, a emergency release, który wymaga pełnego code review i QA.

Czym hotfix różni się od zwykłego wydania

Główne różnice między hotfixem a planowanym wydaniem to szybkość, zakres zmian i poziom testowania. Planowane wydanie może obejmować dziesiątki funkcji, przechodzić pełny cykl QA (regression + integration + UI tests) i zajmować 1-2 tygodnie od code freeze do wdrożenia. Hotfix zawiera jedną-dwie poprawki, przechodzi przyspieszony przegląd (2 approvals zamiast 3) i minimalny smoke test.

Z punktu widzenia procesu Git, hotfix tworzony jest od taga wydania, a nie z gałęzi develop. Gwarantuje to, że do hotfixa trafią tylko zmiany niezbędne do usunięcia problemu, bez przypadkowego przechwycenia niedokończonych funkcji z develop. Po wdrożeniu hotfix jest scalany z powrotem do main i develop (przez cherry-pick lub merge).

Porównanie planowanego wydania i hotfixa

Ważne: nie każde pilne zadanie to hotfix. Jeśli menedżer mówi „pilnie trzeba dodać przycisk” — to nie jest hotfix, tylko priority shift. Prawdziwy hotfix definiuje severity dla użytkownika, a nie pilność dla biznesu. Kryterium: jeśli aplikacja nie pada i dane nie wyciekają — zadanie czeka na planowane wydanie.

Proces hotfixa: od wykrycia do wdrożenia

Pierwszym krokiem po wykryciu krytycznego problemu jest triage — szybka ocena severity. Dyżurny programista (on-call engineer) potwierdza błąd, sprawdza logi i crash reports, określa, czy problem jest regresją ostatniego wydania, czy długo żyjącym błędem. Jeśli severity P0 — uruchamiany jest hotfix pipeline. Etap triage nie powinien zajmować więcej niż 15 minut.

Drugi krok — utworzenie gałęzi od ostatniego taga wydania (v2.5.0 → hotfix/v2.5.1). Programista wprowadza minimalną poprawkę, commit z prefiksem HOTFIX w komunikacie, push i otwiera PR z oznaczeniem [HOTFIX]. Fast-track code review: dwóch recenzentów jest przypisywanych automatycznie przez CODEOWNERS, czas recenzji — nie więcej niż 30 minut. Jeśli nie ma zmian przez 20 minut — recenzent jest pomijany, wyznaczany jest następny.

Trzeci krok — budowanie i wdrożenie przez CI/CD. Hotfix pipeline różni się od zwykłego: pomijane są długie testy integracyjne (zajmujące godziny), uruchamiany jest tylko smoke suite (10-15 krytycznych scenariuszy, 5-10 minut). Po wdrożeniu monitoring: crash rate, error rate, API latency — przez 30 minut. DORA metrics dla hotfixów: czas odzyskiwania (MTTR) powinien wynosić mniej niż 1 godzinę.

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

W tym pipeline kluczowe optymalizacje: sprawdzenie diffa (nie więcej niż 30 linii), pominięcie testów integracyjnych, automatyczne wdrożenie na staging i production przy udanym smoke teście. HOTFIX_MODE env-zmienna włącza dodatkowe sprawdzenia w runtime — na przykład rozszerzone logowanie dla szybkiej diagnostyki problemów.

Gałęzie hotfix w Git: prawidłowa strategia

Strategia pracy z gałęziami hotfix jest opisana w Gitflow Workflow. Główna zasada: gałąź hotfix jest tworzona od ostatniego taga wydania (git checkout -b hotfix/v2.5.1 tags/v2.5.0), a nie z develop lub main. Gwarantuje to, że hotfix bazuje na tym samym stanie kodu, który jest aktualnie na produkcji, i nie przechwytuje niedokończonych zmian z develop.

Po zakończeniu poprawki gałąź hotfix jest scalana z main (lub master) i develop. Do main — zwykły merge commit z tagiem nowego wydania poprawkowego (v2.5.1). Do develop — merge lub cherry-pick, w zależności od polityki zespołu. Jeśli develop zawiera więcej zmian niż main, zaleca się cherry-pick konkretnego commita hotfixa, aby uniknąć konfliktów. GitFlow zaleca scalanie hotfix do main w pierwszej kolejności, a następnie scalanie main do develop.

# Utwórz gałąź hotfix z ostatniego taga wydania
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Zastosuj poprawkę
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Scal do main i oznacz tag wydania
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Scal również do develop
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Usuń tymczasową gałąź
git branch -d hotfix/v2.5.1

Ważne: jeśli hotfix naprawia błąd istniejący w bieżącej gałęzi develop (błąd został wprowadzony kilka sprintów temu), to po scaleniu hotfix do main i develop, develop już zawiera poprawkę. Jeśli natomiast błąd został wprowadzony tylko w gałęzi wydania (przez cherry-pick nagromadził się błąd), to w develop poprawka może nie być potrzebna. Root cause analysis pomaga określić, czy cherry-pick w develop jest potrzebny.

Ryzyka hotfixów i jak je minimalizować

Główne ryzyko hotfixa — wprowadzenie nowego, poważniejszego błędu z powodu pośpiechu. Według badań Stripe (2021), 15% hotfixów powoduje regresję i wymaga drugiego hotfixa. To prawo podłości: im szybciej naprawiamy, tym większe prawdopodobieństwo pomyłki. Minimalizacja ryzyka osiągana jest przez ścisłe ograniczenie rozmiaru diff (nie więcej niż 30 linii) i obowiązkowy automatyczny smoke test.

Drugie ryzyko — narastanie długu technicznego. Jeśli zespół regularnie używa hotfixów zamiast planowanych wydań, baza kodu degraduje: commity hotfix nie przechodzą refaktoryzacji, tymczasowe rozwiązania nie są zastępowane prawidłowymi, dokumentacja nie jest aktualizowana. Health check: jeśli hotfixy są wydawane częściej niż raz w miesiącu — proces wydawniczy wymaga przeglądu.

Trzecie ryzyko — psychologiczne. Regularne hotfixy wypalają zespół: programiści on-call są w ciągłym stresie, code review staje się formalnością (wszyscy chcą jak najszybciej), kultura jakości spada. Normalna częstotliwość hotfixów dla dojrzałego zespołu to 1-2 na kwartał. Jeśli więcej — problem nie leży w hotfixach, ale w jakości planowanych wydań.

Co robić po hotfixie

Po wdrożeniu hotfixa i stabilizacji metryk przeprowadza się post-mortem (blameless retrospective). Zespół odpowiada na cztery pytania: co się stało, dlaczego testy nie wykryły błędu, co zrobiono w celu naprawy, jak zapobiec powtórzeniu. Post-mortem przeprowadza się w ciągu 24-48 godzin po hotfixie, póki szczegóły są świeże w pamięci. Blameless culture — kluczowa zasada: omawia się procesy, a nie ludzi.

Rezultat post-mortem — concrete action items z osobami odpowiedzialnymi i terminami. Typowe action items: dodać unit test na przypadek, który przeoczono, rozszerzyć smoke test suite, poprawić monitoring (dodać alert na metrykę), zaktualizować runbook dla podobnych incydentów. Action items powinny być wykonane przed następnym planowanym wydaniem.