Стратегия ветвления Git для новой бережливой команды

У нас есть веб-приложение, для которого у нас есть пара корпоративных клиентов. Недавно мы решили предложить его как приложение SaaS и следовать бережливому подходу (параллельно с нашим корпоративным предложением). Это означает, что у нас есть эксперименты на ходу, которые могут не попасть в производство.

До того, как мы перешли на бережливое производство, нам нравилась следующая стратегия ветвления (я считаю, что она довольно стандартна):

  • основной — всегда стабильный
  • dev – часто нестабильный (функциональные ветки отрезаются от dev, чтобы новые функции вошли в следующий основной выпуск)
  • major_release_x — live (обрез мастера после слияния dev с master, здесь происходит исправление ошибок и слияние обратно с master и dev)

Теперь у нас есть следующее в дополнение к вышеперечисленному, и это не работает так хорошо:

  • lean_release_branch — живая (отрезана от major_release_x и содержит эксперименты)
  • experiment_x – отрезать major_release_x (здесь мы взламываем функцию вместе, а затем объединяем ее в lean_release_branch)

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

Проблема в том, что мы не можем создать функциональную ветку от dev (поскольку она, скорее всего, нестабильна) и мы не можем создать функциональную ветку от lean_release_branch для двух причины:

  1. он был заражен кодом эксперимента, поэтому это изменение/функция не сможет вернуться к мастеру.
  2. lean_release_branch всегда должен быть готов к выпуску, поэтому мы не можем быть заняты его тестированием и исправлением (после объединения с ним изменения/функции), если есть критическая проблема, которую необходимо исправить. и выпустил

Кто-нибудь знает лучшую стратегию для нашей установки?


git branch git-branch branching-strategy
person Markus Coetzee    schedule 27.06.2013    source источник
comment
в предпоследнем абзаце вы имеете в виду, что после хороших отзывов об эксперименте переделанная функция должна стать частью бережливого релиза? Когда он станет частью основного релиза?   -  person Niel de Wet    schedule 28.06.2013
comment
@NieldeWet Твердые отзывы, о которых я говорю, касаются чего-то, не связанного с экспериментом. Таким образом, нам нужно будет сразу же начать производство и как можно скорее выпустить его из ветки lean_release_branch, а затем он должен найти путь в разработку, чтобы перейти к будущему основному выпуску.   -  person Markus Coetzee    schedule 28.06.2013

Ответы (3)


arrow_upward
2
arrow_downward

Помимо GitFlow, упомянутого Нозари, есть также GitHub Flow. Место, где я работаю, использовало это в качестве основы (мастер всегда стабилен, разрабатывается в функциональных ветках, пулл-реквест с обзором перед слиянием). Мы развертываем реже, чем GitHub, поэтому на мастере мы используем аннотированные теги. для отслеживания релизов, а облегченные теги указывают на любой коммит, который сейчас находится в стадии подготовки/производства. Этим управляет гем Ruby capistrano-deploytags.

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

person Rafe    schedule 28.06.2013

arrow_upward
0
arrow_downward

Я только что перешел с TFS на GIT, и модель, которой я следую, основана на этой сообщение.

Что касается ваших экспериментов, это просто «избранные ветки», которые не вернутся в разработку (слились в разработку).

person nozari    schedule 28.06.2013
comment
возможно, немного другой взгляд на рабочий процесс nvie: speakerdeck.com/ewoodh2o/a-sane- рабочий процесс git - person Zavael; 30.10.2013

arrow_upward
0
arrow_downward

Поскольку все в major_release_x уже находится в dev (поскольку dev было объединено с master перед последним основным выпуском), производственная функция (после успешного эксперимента) может быть реализована в ответвлении функции от major_release_x, названа production_feature_y, а затем объединена с обоими dev, для следующего основного выпуска и lean_release_branch.

Таким образом, новые производственные функции доступны в вашем бережливом выпуске и будут в следующем основном выпуске, а бережливую ветку больше не нужно объединять.

Дальнейшие отзывы клиентов об этой функции могут быть реализованы в production_feature_y и снова объединены в dev и lean_release_branch.

Исправления ошибок могут обрабатываться таким же образом, выполняться в ответвлении от major_release_x и объединяться как в major_release_x, так и в lean_release_branch.

person Niel de Wet    schedule 28.06.2013
comment
Именно так мы подготовили пару отзывов, но это работает не слишком хорошо, так как нарушает пункт №. 2: ветка lean_release_branch всегда должна быть готова к выпуску, поэтому мы не можем быть заняты ее тестированием и исправлением (после слияния с ней изменения/функции), если есть критическая проблема, которую необходимо исправить и выпустить - person Markus Coetzee; 28.06.2013
comment
Хорошо, но если вы делаете производственную функцию в своей собственной ветке, наверняка к тому времени, когда она будет объединена, она должна быть готова к производству и готова к выпуску? - person Niel de Wet; 28.06.2013
comment
Сначала он должен быть выпущен на тестовый сервер после проверки кода и тестирования разработчиком в своей функциональной ветке, поэтому он должен перейти в ветку с заданием сборки (но не в ветку Lean_release_branch, поскольку она должна быть на 100% стабильной). . - person Markus Coetzee; 28.06.2013
comment
@MarkusCoetzee, разве не для этого предназначена ваша ветка dev? - person Niel de Wet; 28.06.2013
comment
это неплохая идея, но dev и ветка lean_release_branch могут сильно отличаться друг от друга. В идеале эта ветвь должна быть как можно ближе к ветке lean_release_branch, чтобы не было сюрпризов при слиянии с веткой lean_release_branch. - person Markus Coetzee; 28.06.2013