Как организовать процесс работы с хотфиксами (hotfix)?

Хотфикс (hotfix) — это срочное исправление критического бага в production-окружении. Процесс должен быть быстрым, но контролируемым, чтобы минимизировать риски.

Пошаговый процесс работы с хотфиксом:

1. Обнаружение и оценка:

   • Баг обнаруживается в production.
   • Команда (тимлид, продакт-оунер) оценивает критичность: является ли проблема блокирующей для бизнеса или пользователей? Если да — инициируется хотфикс.

2. Создание ветки:

   • Ветка создается от тега или коммита, соответствующего production-версии (чаще от main или master), а не от текущей develop.
   • Именование: hotfix/краткое-описание или hotfix/v1.2.1.

     git checkout -b hotfix/login-auth-crash main

3. Внесение исправления:

   • Вносятся минимально необходимые изменения для решения конкретной проблемы. Рефакторинг и доработки недопустимы.
   • Пишется тест, воспроизводящий баг (если возможно).

4. Локальная проверка и тестирование:

   • Разработчик проверяет исправление локально.
   • Изменения мержатся в специальное hotfix-окружение (staging, максимально близкое к prod), где QA проводит срочное тестирование.

5. Деплой в production:

   • После успешного тестирования изменения мержатся обратно в main и создается новый тег версии (например, v1.2.1).
   • Запускается упрощенный, но надежный CI/CD пайплайн для деплоя. Часто требуется ручной approve ответственного лица.

     git checkout main
     git merge --no-ff hotfix/login-auth-crash
     git tag -a v1.2.1 -m "Hotfix: исправление падения при авторизации"
     git push origin main --tags

6. Синхронизация с основной веткой разработки:

   • Важный шаг! Изменения из хотфикса необходимо перенести в develop (или текущую ветку разработки), чтобы избежать регрессии в будущем.

     git checkout develop
     git merge main # Или cherry-pick коммита хотфикса

Ключевые принципы:

• Минимальность изменений. Только исправление бага.
• Контроль. Обязательное code review, даже в сжатые сроки.
• Тестирование. Хотя бы минимальное smoke-тестирование на изолированном окружении.
• Документирование. Четкое описание бага и решения в коммите и тикете.
• Коммуникация. Уведомление всех заинтересованных сторон (поддержка, менеджмент) о планируемом и выполненном деплое.