Что делать, если баг попал в прод?
Привет, Хабр! Если вы давно искали подборку полезных статей по Git и Gitflow — загляните в блог beeline cloud. Здесь я делюсь личным опытом, погружаюсь в задачи из практики и даю развернутые комментарии на конкретную тему.
И да, меня по-прежнему зовут Николай Пискунов, я руководитель направления Big Data. Сегодня поговорим о том, что делать, если баг, несмотря на усилия тестировщиков, все же попал в прод.
На помощь приходит Hotfix
Только не это! Баг попал в прод!
Это самый ужасный момент, особенно, когда репорт на баг кидают пользователи приложения. В этом случае нужно как можно быстрее пофиксить баг и разобраться с последствиями. Тут нам поможет бэтман Hotfix.
В методологии GitFlow Hotfix представляет собой процесс быстрого исправления ошибок в продуктивной версии приложения. Он позволяет команде разработчиков быстро реагировать на проблемы, которые требуют немедленного внимания. И самое важное — не нужно ждать завершения текущих разработок в других ветках.
Ветка Hotfix создается из ветки master, а после мерджится обратно в master и в ветку разработки develop. Это позволяет быстро и безопасно исправлять ошибки в уже выпущенном продукте, не затрагивая основную кодовую базу.
Hotfix-ветка имеет несколько отличий от других типов изменений в GitFlow:
Создается из ветки master, а не из develop.
Мерджится в develop и master.
Имеет приоритет над другими изменениями, поэтому они должны быть включены в следующую версию продукта.
Таким образом, Hotfix-ветка позволяет быстро и безопасно исправлять ошибки в уже выпущенном продукте, обеспечивая стабильность и надежность вашего проекта.
Как Hotfix работает в GitFlow?
Отмечу ключевые поинты:
Создание ветки Hotfix. Когда в продуктивной версии фиксируется ошибка, от текущей стабильной ветки создается новая ветка. Обычно это master. Ветку принято называть по типу ошибки, например, hotfix/issue-description.
Исправление ошибки. В ветке Hotfix вносятся изменения, необходимые для исправления ошибки.
Тестирование. После внесения изменений их важно протестировать. Тут важно проверить, что ошибка исправлена и это не вызывает новых проблем.
Слияние (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
Эти команды помогают управлять версиями проекта.
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. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
