Хотфікс в розробці додатків: суть, механізм та як застосовувати

Що таке хотфікс і коли він потрібен?

Хотфікс (гаряче виправлення) — це патч для продакшен-версії застосунку, випущений поза чергою для усунення критичної проблеми. Хотфікс доставляється користувачам за години, а не дні, і призначений виключно для ситуацій, коли застосунок недоступний, втрачає дані або порушує безпеку користувачів.

Типові сценарії для хотфікса: краш при запуску на певних пристроях (регресія після останнього релізу), витік персональних даних через некоректну авторизацію, неробоча платіжна інтеграція (втрата доходу), порушення GDPR/CCPA compliance. Усі ці ситуації мають severity P0 або P1 у класифікації інцидентів. Планові завдання — оптимізація, рефакторинг, новий екран — ніколи не робляться через hotfix.

Важливе правило: хотфікс містить мінімальну кількість змін (1-2 файли, 10-20 рядків коду). Чим менший diff, тим нижчий ризик внести нову помилку. Якщо для виправлення потрібно змінити архітектуру або додати новий модуль — це не хотфікс, а emergency release, який потребує повноцінного code review та QA.

Чим хотфікс відрізняється від звичайного релізу

Головні відмінності хотфікса від планового релізу — швидкість, обсяг змін та рівень перевірок. Плановий реліз може включати десятки фіч, проходити повний QA cycle (regression + integration + UI tests) і займати 1-2 тижні від code freeze до деплою. Хотфікс включає одне-два виправлення, проходить прискорене рев'ю (2 approvals замість 3) та мінімальний smoke test.

З точки зору Git-процесу, хотфікс створюється від релізного тега, а не від develop-гілки. Це гарантує, що в хотфікс потраплять тільки зміни, необхідні для виправлення проблеми, без випадкового захоплення незавершених фіч з develop. Після деплою хотфікс мержиться назад у main та develop (через cherry-pick або merge).

Порівняння планового релізу та хотфікса

Важливо: не кожне термінове завдання — хотфікс. Якщо менеджер каже «терміново потрібно додати кнопку» — це не хотфікс, а priority shift. Справжній хотфікс визначається severity для користувача, а не терміновістю для бізнесу. Критерій: якщо застосунок не падає і дані не витікають — завдання чекає планового релізу.

Процес хотфікса: від виявлення до деплою

Першим кроком при виявленні критичної проблеми є triage — швидка оцінка severity. Черговий розробник (on-call engineer) підтверджує баг, перевіряє логи та crash reports, визначає, чи є проблема регресією останнього релізу або довгоживучим багом. Якщо severity P0 — запускається hotfix pipeline. Стадія triage не повинна займати більше 15 хвилин.

Другий крок — створення гілки від останнього релізного тега (v2.5.0 → hotfix/v2.5.1). Розробник вносить мінімальне виправлення, комітить з префіксом HOTFIX у повідомленні, пушить і відкриває PR з позначкою [HOTFIX]. Fast-track code review: два рев'ювери призначаються автоматично через CODEOWNERS, час рев'ю — не більше 30 хвилин. Якщо змін немає через 20 хвилин — рев'ювер скіпається, призначається наступний.

Третій крок — збірка та деплой через CI/CD. Hotfix pipeline відрізняється від звичайного: пропускаються довгі integration tests (які займають години), запускається тільки smoke suite (10-15 critical scenarios, 5-10 хвилин). Після деплою моніторинг: crash rate, error rate, API latency — протягом 30 хвилин. DORA metrics для хотфіксів: час відновлення (MTTR) має бути менше 1 години.

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

У цьому пайплайні ключові оптимізації: перевірка diff-а (не більше 30 рядків), пропуск integration tests, автоматичний деплой на стейджинг і production при успішному smoke-тесті. HOTFIX_MODE env-змінна вмикає додаткові перевірки в рантаймі — наприклад, розширене логування для швидкої діагностики проблем.

Hotfix-гілки в Git: правильна стратегія

Стратегія роботи з hotfix-гілками описана в Gitflow Workflow. Основне правило: hotfix-гілка створюється від останнього релізного тега (git checkout -b hotfix/v2.5.1 tags/v2.5.0), а не від develop або main. Це гарантує, що хотфікс базується на тому ж стані коду, який зараз на продакшені, і не захоплює незавершені зміни з develop.

Після завершення фікса hotfix-гілка мержиться в main (або master) і develop. В main — звичайний merge commit з тегом нового патч-релізу (v2.5.1). В develop — merge або cherry-pick, залежно від політики команди. Якщо develop містить більше змін, ніж main, рекомендується cherry-pick конкретного коміта хотфікса, щоб уникнути конфліктів. GitFlow рекомендує мержити hotfix в main першим, а потім мержити main в develop.

# Створити hotfix-гілку від останнього релізного тега
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Застосувати виправлення
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Злити в main та позначити реліз
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Злити також в develop
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Очистити тимчасову гілку
git branch -d hotfix/v2.5.1

Важливо: якщо хотфікс виправляє баг, який існує в поточній develop-гілці (баг був внесений кілька спринтів тому), то після мержа hotfix в main і develop, develop вже містить виправлення. Якщо баг був внесений тільки в релізній гілці (через cherry-pick накопичилася помилка), то в develop виправлення може не знадобитися. Root cause analysis допомагає визначити, чи потрібен cherry-pick в develop.

Ризики хотфіксів і як їх мінімізувати

Головний ризик хотфікса — внесення нової, більш серйозної помилки через поспіх. За даними дослідження Stripe (2021), 15% хотфіксів викликають регресію і вимагають другого хотфікса. Це закон підлості: чим швидше ми виправляємо, тим вища ймовірність помилитися. Мінімізація ризику досягається жорстким обмеженням розміру diff (не більше 30 рядків) та обов'язковим автоматичним smoke test.

Другий ризик — накопичення технічного боргу. Якщо команда регулярно використовує хотфікси замість планових релізів, кодова база деградує: hotfix-коміти не проходять рефакторинг, тимчасові рішення не замінюються правильними, документація не оновлюється. Health check: якщо хотфікси випускаються частіше разу на місяць — процес релізу потребує перегляду.

Третій ризик — психологічний. Регулярні хотфікси випалюють команду: on-call розробники знаходяться в постійному стресі, code review стає формальністю (всі хочуть швидше), культура якості падає. Нормальна частота хотфіксів для зрілої команди — 1-2 на квартал. Якщо більше — проблема не в хотфіксах, а в якості планових релізів.

Що робити після хотфікса

Після деплою хотфікса та стабілізації метрик проводиться post-mortem (blameless retrospective). Команда відповідає на чотири питання: що сталося, чому перевірки не впіймали баг, що зроблено для виправлення, як запобігти повторенню. Post-mortem проводиться протягом 24-48 годин після хотфікса, поки деталі свіжі в пам'яті. Blameless culture — ключовий принцип: обговорюються процеси, а не люди.

Результат post-mortem — concrete action items з відповідальними та строками. Типові action items: додати unit test на кейс, який пропустили, розширити smoke test suite, покращити моніторинг (додати alert на метрику), оновити runbook для аналогічних інцидентів. Action items мають бути виконані до наступного планового релізу.