Виды контроля версий - GitFlow, TBD, Central Workflow
Дорогой Мартин Алексеевич! Менеджеры знают о существовании систем контроля версий. На слуху такие термины, как GIT, SVN, Mercurial и т.п. Однако, предлагаю в этой статье освежить наши знания, а какие бывают паттерны/виды/стратегии контроля версий кода? Ведь в зависимость от выбранного паттерна могут различаться жизненные циклы проекта или продукта.
В этой статье рассмотрим следующие модели систем контроля версий:
Используемые статьи:
* TBD: https://trunkbaseddevelopment.ru/
* Модели систем контроля версий: https://habr.com/ru/companies/avito/articles/680522/
Предыстория
Давным-давно, ещё во времена динозавров программирование осуществлялось на бумажке. Потом перепечатывалось в файл с исходном кодом, а собранные дистрибутивы передавались в виде RAR-архива. Эх... студенческие годы. Было просто и надежно.
Все изменилось, когда придумали Git и Tortoise SVN. И тут всё как закрутилось!
Итак, у нас есть команда из нескольких разработчиков. Вместе мы делаем уникальный продукт в условиях неопределенности и конечности. Как же нам организовать разработку?
Central Workflow
Допустим, у нас маленький пет-прожект с другом. Делаем MVP. Зададимся вопросом, а зачем нам вообще заморочки с какими-то бранчами, релизами, да и полноценным тестированием? Правильно, для MVP - незачем. Давайте все делать сразу в Master.
В итоге Central Workflow подходит:
Git Flow
А что, если у нас не стартап/Pet-проект?
Разберемся с процессом GitFlow на примере реализации новой функцни / фичи. Зафиксируем соглашение, что все новые функции у используют FeatureFlag для их быстрого отключения.
Для коммита в develop-ветку нужно устранить выявленные конфликты.
Ветка release создается каждый раз заново для релиза новых функций.
Важно, что делаем мы их в релиз-ветке, потому что планируем выкатить именно её.
Итого:
- GitFlow сочетается с процессами CI / CD, но требует некоторых телодвижений.
- Процесс сложный, но соответствует здравому смыслу и логичен.
- Подходит для ПО с классическим циклом разработки (параллельная работа над разными версиями, релиз раз несколько месяцев).
GitFlow в зеленом банке
В дополнение к проду, хорошо иметь ещё два стенда:
- DEV. Стенд для разработки. Все новые фичи и починенные баги в рамках спринта в первую очередь выкатываются на этот стенд. Активное тестирование фич и исправленных багов происходит тут. Деплоит на него в основном команда разработки. Содержит синтезированные данные.
- IFT. Стенд для интеграционно‑функционального тестирования. На этапе отладки фичи и исправленные баги тестируются на нём. Как правило, размещается в тестовом окружении заказчика и содержит реальные обезличенные данные.
- PROD. Продуктивный стенд, с реальными пользователями. Вершина иерархии окружения. Деплоем на такие стенды занимается специальная команда внедрения.
Используемые ветки
У нас 3 стенда. Для каждого из них лучше создать свою ветку, назвав её соответствующим образом: prod/master, ift/test, dev/develop. В нашем примере, ветки будут master, test и develop.
Правило первое. Каждый стенд имеет свою одну-единственную мастер-ветку. Разворачивание приложения на стенд происходит только из неё.
Этап разработки
Активная разработка ведётся только из ветки develop. Реализуете фичу - ответвляете ветку feature/XXX от develop. Исправляете баг - пожалуйста, bug/XXX. По окончании разработки, ветка вливается обратно в develop, а оттуда уже изменения попадают на DEV-стенд.
На DEV-стенде размещено приложение в состоянии, соответствующем текущему спринту; на IFT и PROD - предыдущему. Выглядит это так:
Исправляем дефекты
По окончании активной разработки, весь код из ветки develop вливается в ветку test. Тестирование на DEV‑стенде прекращается и переносится на IFT‑стенд. Этот процесс можно назвать code freeze в рамках спринта.
С этого момента, разработчик уже может брать задачи следующего спринта и продолжать реализовывать обычным способом, в ветках от develop, по окончании реализации которых он в обычном режиме деплоится на DEV‑стенд. Происходит разделение стендов на уровне спринтов: IFT‑стенд принадлежит текущему спринту, тогда как DEV‑стенд — будущему.
Таким образом, на этапе отладки каждый стенд находится в версии своего спринта: тогда как PROD всё ещё в версии предыдущего спринта, то IFT уже в версии нынешнего, а DEV — в версии спринта будущего.
Тестировщик нашёл новый баг. Как мы помним, IFT находится в состоянии текущего спринта, а DEV — будущего. Если мы для устранения бага создадим ветку от develop, то к тому моменту в develop уже могут оказаться фичи следующего релиза, которые не были ещё протестированы и не должны попасть в текущий релиз. Тогда, после устранения бага, нам придётся черри‑пикать изменения из develop в test и держать потом эти черри‑пики в уме, но это плохой выход из ситуации (в целом, практика черри‑пиков является костылём и в разработке может применяться только от безысходности).
Полный цикл разработки в спринте
Trunk Based Development
Модель ветвления в системе контроля версий, в которой разработчики работают над кодом в единственной ветке master/trunk. Эта модель позволяет не создавать другие долгоживущие ветки и описывает технику как именно это делать.
Характеризуется всего тремя типами веток и итеративным подходом к разработке новых функций.
- Создание Feature-ветки для реализации новой функции. Используется FeatureFlag'и для выключения функции.
Т.к. реализация новой функции покрыта Feature Flag'ами, то для пользователей новая функция недоступна. Все готово для релиза Continious Deployment
Как только функция доработана и протестирована, то всё готово к релизу и включению Feature Flag.
ИТОГО
Все фломастеры на вкус разные, но особенно вкусные GitFlow и TBD. Самые вкусные - это гибридная и удобная модель для вас.
Для Pet-проектов, где настроен CI / CD, IMHO, удобно использовать Trunk Based Development:
- Минимум конфликтов при разработке.
- Готовность к релизам в любой момент без подготовки.
- Очень быстрая и качественная обратная связь на PR\MR.
Плюсом TBD является сокращение времени Time-to-Market, а это в современных реалиях очень важно для бизнеса.