Руководство по git-ветвлению / стратегии выпуска

Question

Я ищу руководство по стратегии ветвления / выпуска git, которая, похоже, не похожа ни на одну из стратегий, которые я нашел до сих пор.

Мы используем VSTS и в настоящее время у нас есть мастерветвь с функциональными ветвями для каждого изменения.PR представляется для проверки ветви функции и, в случае одобрения, автоматически объединяется в master.Это автоматически запускает выпуск в среду DEV.Предполагая, что все прошло успешно, релиз запускается вручную (с одобрения).

Проблема, с которой я столкнулся, заключается в том, что у нас может быть несколько членов команды, работающих над различными функциями в любой момент времени.Это означает, что несколько слияний в master с соответствующим выпуском в DEV.Все это прекрасно работает.Проблемы возникают, однако, когда кто-то хочет перенести свои изменения в производство до того, как все остальные будут готовы.В нашем текущем сценарии выполнение выпуска в производство включает в себя все: от основной ветви, существовавшей на момент выпуска, до DEV.

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

Я рассмотрел несколько веток и коммитов по сбору вишни, но это кажется слишком сложным.

Я надеюсь, что мне не хватаетчто-то довольно очевидное.

Answer 1

Gitflow, который я предлагаю, как показано ниже:

• Каждый разработчик работает над своей собственной ветвью функций
• Когда разработчик завершит свою работу, создайте PR для объединения ветви функций в develop ветвь
• Когда одобрен PR, объедините переход из функциональной ветви в develop ветку.Затем релиз будет запущен для развертывания в среде DEV.
• Когда он будет готов к развертыванию в производственной среде, объедините ветвь develop в ветку master для производства.

И выможно также сослаться на успешную модель ветвления Git для более подробной информации о модели ветвления.

Answer 2

Я подозреваю, что вы уже знаете это, но

Это может показаться очень неправильным, но в нашем репозитории Git на самом деле нет кода - его следует рассматривать скорее как конфигурацию.Вполне допустимо независимо переносить изменения конфигурации в производство.

конфликтует с вашим утверждением здесь:

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

Если ваши изменения могут находиться в состоянии, когда они не готовы вместе, по определению вам нужен какой-то способ их поэтапного выполнения.В прошлом я использовал несколько различных стратегий, каждая из которых вращается вокруг идеи, которая сливается с основной и разворачивается до производства, что в корне заслуживает атомарной операции:

1. Уменьшитьвремя, когда изменения остаются в основной ветке без перехода к продукту.При необходимости откатите изменения, которые являются неудовлетворительными.Для меня это не полное решение, потому что оно не дает людям доступ к вашей среде разработки или подготовки к работе в течение длительного периода времени, в котором они могут нуждаться.
2. Держите отдельные ветви Dev и Main и будьте готовычтобы вишня слилась с главной.Это не полностью решает вашу проблему, потому что в большинстве сценариев, если несколько изменений конфигурации могут загрязнять друг друга в Main, они также могут делать это в Dev, что может изменить результаты вашего теста (как они это делают в текущей системе).
3. Изучите свою инфраструктуру разработки и перепроектируйте ее так, чтобы сборки разработки могли быть протестированы надлежащим образом без слияния.Затем настройте (стробированную) стратегию непрерывного развертывания таким образом, чтобы при слиянии с main вы всегда выходили на работу.Эта стратегия может потребовать много работы для начала, но, вероятно, она наиболее близка к производственной среде, с которой я сталкивался в крупных компаниях без специальной команды по сборке инфраструктуры.