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

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

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

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

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

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

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

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

Преимущества использования 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.

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

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.