Что делать, если баг попал в прод?

Привет, Хабр! Если вы давно искали подборку полезных статей по Git и Gitflow — загляните в блог beeline cloud. Здесь я делюсь личным опытом, погружаюсь в задачи из практики и даю развернутые комментарии на конкретную тему. 

И да, меня по-прежнему зовут Николай Пискунов, я руководитель направления Big Data. Сегодня поговорим о том, что делать, если баг, несмотря на усилия тестировщиков, все же попал в прод.

На помощь приходит Hotfix

Только не это! Баг попал в прод!

Это самый ужасный момент, особенно, когда репорт на баг кидают пользователи приложения. В этом случае нужно как можно быстрее пофиксить баг и разобраться с последствиями. Тут нам поможет бэтман Hotfix.

В методологии GitFlow Hotfix представляет собой процесс быстрого исправления ошибок в продуктивной версии приложения. Он позволяет команде разработчиков быстро реагировать на проблемы, которые требуют немедленного внимания. И самое важное — не нужно ждать завершения текущих разработок в других ветках.

Ветка Hotfix создается из ветки master, а после мерджится обратно в master и в ветку разработки develop. Это позволяет быстро и безопасно исправлять ошибки в уже выпущенном продукте, не затрагивая основную кодовую базу.

Hotfix-ветка имеет несколько отличий от других типов изменений в GitFlow:

• Создается из ветки master, а не из develop.

• Мерджится в develop и master.

• Имеет приоритет над другими изменениями, поэтому они должны быть включены в следующую версию продукта.

Таким образом, Hotfix-ветка позволяет быстро и безопасно исправлять ошибки в уже выпущенном продукте, обеспечивая стабильность и надежность вашего проекта.

Как Hotfix работает в GitFlow?

Отмечу ключевые поинты: 

1. Создание ветки Hotfix. Когда в продуктивной версии фиксируется ошибка, от текущей стабильной ветки создается новая ветка. Обычно это master. Ветку принято называть по типу ошибки, например, hotfix/issue-description.

2. Исправление ошибки. В ветке Hotfix вносятся изменения, необходимые для исправления ошибки.

3. Тестирование. После внесения изменений их важно протестировать. Тут важно проверить, что ошибка исправлена и это не вызывает новых проблем.

4. Слияние (merge). После успешного тестирования ветка Hotfix сливается обратно в основную (обычно master) и ветку для разработки (например, develop), чтобы изменения были доступны в будущих релизах.

Преимущества использования Hotfix в GitFlow заключаются в том, что он позволяет быстро решить критические проблемы, минимизируя время простоя и сохраняя целостность рабочей среды. Обычно хотфиксы вносят или старшие разработчики, или старшие тестировщики.

Время исправлять ошибки

Предположим, что в коде, который был выпущен в прод закралась ошибка. Согласно вышеописанному алгоритму мы должны создать ветку Hotfix из master. Для простоты назовем ее hotfix/fix_1

Допустим, разработчики забыли сделать форматирование имени пользователя, а тестировщики не обратили на это внимание. В результате в ответе отдается некорректный формат имени. Ждать следующего релиза долго, а на исправление уйдет 10 минут.

Обычно в подобных случаях старший разработчик или тимлид переключается на ветку Hotfix, вносит изменения, коммитит их и заливает в удаленный репозиторий.

После этого создаются 2 запроса на слияние для обеспечения консистентности кода в разных ветках проекта: первый, чтобы изменения попали в ветку master и фикс как можно быстрее попал в прод; второй, чтобы изменения попали в ветку develop и были доступны для остальных разработчиков.

Единственное здесь возможен конфликт слияния в ветку develop. Это может произойти в том случае, если разработчики уже успели слить в нее какие-либо изменения. И это вполне реальный кейс, ведь разработка не стоит на месте.

После этого можно получить от тестировщиков апрув на выкатку и деплоить текущий фикс на прод. Вот некоторые команды Git, которые помогут и разнообразят работу:

1. git config —global user.name «Ваше имя» — устанавливает имя в системе.

2. git config —global user.email «ваша почта@email.com» — устанавливает электронную почту.

Благодаря этим командам Git коллеги узнают, кто вносил изменения в код. Большинство IDE и редакторов кода умеют красиво визуализировать такую информацию. Например в VS code эта информация представлена так:

3. git config —global color.ui true — включает цветовую тему в терминале для Git. Это позволяет использовать разные цвета для вывода различных типов информации, что делает вывод более понятным и читабельным. Например, изменения будут выделяться одним цветом, коммиты — другим, ссылки — третьим и так далее.

 4. git config —list — выводит список всех настроек Git с их текущими значениями. Это может быть полезно для просмотра настроек, чтобы убедиться в их корректности или для изменения каких-либо параметров, даже если вы не знаете их названия. Информацию по настройкам также можно посмотреть в файле .git/config в папке вашего проекта.

 5. git init — инициализирует новый репозиторий.
git clone <url> — скачивает репозиторий с указанного URL.

Эти команды помогают управлять версиями проекта.

6. git status — показывает текущее состояние репозитория.

git commit -m «комментарий»` — делает коммит с указанным комментарием.
git add <файл> — добавляет файл в индекс для последующего коммита.

С помощью этих двух команд вы можете зафиксировать состояние проекта. В последствии есть возможность откатиться к этим изменениям или просмотреть, что происходило в конкретном коммите.

В VS code можно также просмотреть изменения и закоммитить их:

7. git log — показывает историю изменений по коммитам. Опять же, большинство IDE и редакторов кода умеют красиво визуализировать такую информацию. Вот как это выглядит в VS code:

Посмотреть, какие изменения происходили в определенном файле можно с помощью команды:
git log -p Название Файла:

9. git pull   — забирает изменения из удаленного репозитория.

10. git push  — отправляет изменения в удаленный репозиторий.

 Это лишь основные команды для начала работы с Git.

Подведем итоги

Gitflow —  это простой и гибкий процесс управления версиями с помощью Git, который помогает командам выполнять изменения в коде. Основная цель — упростить и автоматизировать процесс принятия решений о том, какие изменения и каким образом нужно включить в основную ветку.

Gitflow подходит для разработки популярных на сегодняшний день проектов на основе микросервисной архитектуры. Но, конечно, существуют и легаси проекты с огромной кодовой базой над которой работают сразу несколько сотен разработчиков. В таком случае появляются дополнительные шаги, которые не входят в классический Gitflow.

beeline cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.