Адаптация модели git-flow для предпроизводственной среды

Question

Я думаю о расширении модели git-flow для моего текущего рабочего места, в связи с конкретным сценарием. Но мой сценарий настолько распространен, что я удивлен, что никто не делал этого раньше с моделью git-flow, и это заставляет меня думать, что я пропустил очевидную проблему. Мой вопрос: является ли мое предложенное расширение некорректным?

Сценарий: у меня есть несколько команд разработчиков, которые разрабатывают из общей кодовой базы, и мы выпускаем выпуски через несколько (постоянных) сред: сначала в среду системной интеграции (SIT), затем в среду UAT, затем в pre-prod и, наконец, к производству. Это строго последовательно, хотя любой кандидат на выпуск может потерпеть неудачу в любой среде, и, следовательно, не делать это дальше. Таким образом, каждая более поздняя среда является просто более медленной версией предыдущей среды.

Мы вводим git для управления исходным кодом, нам нужен рабочий процесс, и git-flow выглядит как хорошее начало.

Мы спрашивали себя, как захватить (то есть как узнать), что находится в каждой среде в любое время. Модель git-flow имеет два основных состояния: master а также develop, У них "бесконечная продолжительность жизни". Другие ветви - это просто "поддерживающие ветви" с "ограниченным временем жизни". Они существуют только для того, чтобы позволить разработку и перейти от разработки к производству (через состояние временного выпуска). Модель git-flow основана на переходе от разработки к выпуску.

Однако это логически не соответствует нашему сценарию с его последовательностью многоэтапного выпуска. Я в порядке с develop ветка, конечно. И master Филиал явно соответствует нашей производственной среде. Оригинальное описание git-flow говорит об этом master:

Поэтому каждый раз, когда изменения объединяются с основным, это новый производственный выпуск по определению. Мы, как правило, очень строги в этом, так что теоретически мы могли бы использовать скрипт Git Hook для автоматической сборки и развертывания нашего программного обеспечения на наших производственных серверах каждый раз, когда выполнялся коммит на master.

поскольку master Это непрерывный отчет о производстве, кажется последовательным, что мы должны расширить модель git-flow, чтобы иметь соответствующие ветви для SIT, UAT и pre-prod. В конце концов, это постоянные среды со строгими процедурами выпуска. Они просто меняются немного быстрее, чем производство.

Эти дополнительные, постоянные ветви сидят между develop а также masterтак же, как их соответствующие среды.

Теперь это означает, что легко отслеживать выпуски для каждой среды и состояние каждой среды. И слияния для каждого также проще: ветвь SIT требует слияния developветвь UAT требует слияния из ветки SIT, ветвь pre-prod требует слияния с ветки UAT и, наконец, master ветка (для производства) требует слияния с веткой pre-prod. Каждая более поздняя ветвь является просто более медленной версией предыдущей ветки.

Я что-то пропустил?

Answer 1

Я не вижу причин для адаптации потока к вашей модели. Вы говорите, что работаете последовательно SIT -> UAT -> Pre-Prod. Отлично. Как только разработка станет стабильной (т.е. все функции, ожидаемые к выпуску, будут закончены [ed]), тогда сделайте release start и переместите это на свою платформу SIT для обеспечения качества. После начала выпуска разработка может продолжаться на develop ветка. master остается статичным, пока релиз не будет завершен.

Как только QA удовлетворен, ветвь релиза перемещается в UAT. UAT проходит и код накатывает жить а ты выполняешь release finish слиться с мастером / развиваться.

master всегда должно быть отражением того, что в настоящее время находится на живой платформе, в то время как develop является отражением кода в процессе активной разработки. release ветви содержат статический разрез развития, к которому применяются исправления ошибок (в эту ветку не добавляются новые функции, или вы не используете git-flow).

Исходя из вашего описания, я склонен сказать, что вы неправильно поняли модель git-flow, потому что, насколько я вижу, она идеально вписывается в сценарий, который вы описываете, все, что вам нужно заботиться во время SIT -> UAT -> Pre -Прод - ветвь релиза, "забыть" мастер / разработать даже существовать на этом этапе.

Ответ на комментарии

С тех пор, как я впервые опубликовал этот ответ, появилось несколько комментариев, в которых поднимались вопросы о том, как работает модель в ряде различных сценариев.

1. Клиент запросил улучшения существующих функций

Ответ:

НЕ (я не могу подчеркнуть это достаточно сильно) разрешить добавление новых функций / улучшений в ветку релиза. Это ползучесть области. Новые функции - новая работа. Они должны быть оценены отдельно и должны рассматриваться отдельно. Является ли ваш клиент вашей собственной компанией или третьей стороной, они понимают только стоимость. Укажите им, что, если они прервут выпуск, это задержит его [на неопределенный срок] или существующее тестирование пострадает. Относитесь к ветке релиза как master, Это священно. Разрешены только исправления ошибок.

2. Отрасль долголетия

Если ваша ветвь выпуска длится несколько месяцев, ваш цикл выпуска слишком длинный. Я работал в местах, где цикл выпускался, в среднем каждые 3 недели, и в других местах, где мы выпускали каждые пару дней. 3 недели должно быть достаточно для QA и UAT ветки релиза. Если вы смотрите на более длинный цикл, то я бы сказал, что компания не является гибкой и

1. git-flow - неправильная стратегия ветвления (сомнительно, она работает практически в любом сценарии, если она тщательно управляется)

2. Вы серьезно должны бросить вызов компании о том, почему у них такой длинный цикл

3. (скорее всего) - вы не понимаете Git-Flow

   3. CI

Я очень успешно использовал Git-Flow с CI. Хотя в основном это были Jenkins и Bamboo, он также работает с Travis CI.

Git Hook, основанный на коммитах - это именно то, как работает любая ветка. Лучшие примеры, которые я использовал, автоматически собирают, как только коммит (или серия коммитов) передается на пульт, затем включается ловушка и вызывает платформу CI. Затем платформа CI находит соответствующее задание (используя встроенные шаблоны или сторонний модуль) для запуска сборки.

Моя личная установка - запускать локальный экземпляр Jenkins, когда:

• Я создаю ветку (создает новую работу в локальной установке jenkins, предназначенной для текущей ветки)
• Я фиксирую (запускает локальную сборку экземпляра текущей ветки)
• Локальная сборка проходит, может автоматически выдвигаться на удаленный
• Я нажимаю новую ветку (создает целевую сборку в удаленном CI
• Я нажимаю коммиты (запускает удаленный экземпляр CI)
• Удаляю локальную ветку (удаляет локальную работу)
• Удаляю удаленную ветку (удаляет удаленную работу)
• Я поднимаю запрос на слияние (функция мягкого слияния /A в разработку и тесты - тесты не пройдены, слияние отклоняется автоматически)

Это требует некоторой конфигурации, но это возможно с любой современной платформой CI.

Как и все остальное, правила использования Git-Flow являются лишь ориентировочными. Здесь нет жестких и быстрых правил. Если вы хотите долгоживущую ветвь релиза, то это ваш выбор, НО, если вы не будете обращать на них внимание, вы в конечном итоге получите расходящуюся кодовую базу, которая станет адом для слияния воедино.

Git-Flow, как и все, что рождается из инструментов * nix, - это просто способ работы, и с ним приходит большой выбор. Инструмент и рабочий процесс - не более чем оболочка для GIT. Как вы решите реализовать это полностью зависит от вас.