Остановка разработчиков, совершающих неправильные ветки в DVCS

Проблема

Я работаю над программным проектом, в котором участвует около 10 разработчиков, мы делимся исходным кодом через Mercurial. У нас есть ветка разработки и производства в каждом выпуске. Неоднократно в течение проекта у нас был исходный код из одной ветви, т.е. v1, попадающий в ветки исправлений и поддержки для более ранних выпусков программного обеспечения, т.е. v2.

Это приводит либо к тому, что время, потраченное на резервирование неверного коммита, либо к неправильному (возможно, не QAd) коду, достигает и развертывается в неправильной ветви, если мы не заметим, что код попал в неправильную ветку.

Наша отрасль и метод слияния / дизайн

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

Следовательно, мы будем работать над веткой разработки релизов, пока она не будет считаться готовой , ветвить ее для отдельной ветки тестирования / UAT / Production, где выполняются все релизы и сопровождение. Теги используются для создания релизов этой ветки. Пока тестируется v1, для v2 будет создана ветка, и разработчики начнут работать над новыми функциями.

Обычно случается, что разработчик фиксирует работу из-за ветки v2-dev в v1-dev или v1-prod, или, что еще хуже, они объединяют v2-dev в v1-prod (или подобные подобные ошибки).

Мы говорим большинству разработчиков не получать доступ к ветвям -prod , однако код все еще проскальзывает. Группа более старших разработчиков «присматривает» за веткой -prod.

Следует отметить, что, хотя v2 только начала разработку, в v1 все еще могут быть некоторые довольно полезные патчи для исправления проблем. Т.е. v1, возможно, не просто получает странный маленький патч.

Что мы уже пробовали

• Наличие отдельной ветки -prod с привратниками. Ветвь -prod должна выдавать предупреждения через свое имя, и большинству разработчиков не нужно быть в этой ветке. Это на самом деле не уменьшило проблему.
• Повышение осведомленности об этой проблеме среди разработчиков, чтобы попытаться сделать их более бдительными. Опять же, это не очень успешно.

Возможные причины, которые я вижу для разработчиков, совершающих неправильную ветку

• Слишком сложная отраслевая конструкция
• Имея активное развитие в нескольких отраслях параллельно. (У проекта есть признаки использования лавинообразной модели .)
• Разработчики недостаточно хорошо понимают DVCS

Вопросы, которые я прочитал, которые были несколько актуальны

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

С помощью визуальных подсказок мы можем легко включить их в командную строку, однако примерно половина команды использует затмение, в котором я не уверен, как включить визуальные подсказки.

Вопрос

Какие методы, в виде программного обеспечения, управления проектами или управления, мы можем использовать для уменьшения (в идеале, остановки) фиксаций в неправильной ветви, отнимающих наше время или портящих наш развернутый код?

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

Проблема в том, что вы меняете значение ветви как часть процесса.

Изначально v1 devветка для развития. Все новые функции идут туда. В какой-то момент в будущем это станет веткой обслуживания для v1 releaseфилиала. Это суть проблемы.

Дело не в том, что разработчики небрежны, а в том, что права и роли ветки неаккуратны и могут быть изменены.

Что вам нужно сделать, это установить, какую роль играет каждая ветвь, и поддерживать эту роль. Если роль изменится, ветвь.

Например:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

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

Одна статья, которую вы должны прочитать (и, вероятно, она должна преуменьшать значение «следует»), - « Расширенные стратегии ветвления SCM » Стивена Вэнса.

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

В этой статье он определяет пять ролей, которые могут иметь ветви. Иногда ветвь может заполнять две роли, и роли не обязательно нуждаются в новой ветке, если политики ролей не изменяют среднюю ветвь (иногда вы увидите упоминание «ветвь в несовместимой политике»).

Эти роли:

1. Магистраль. Это то, из чего сделаны ветви. Постоянное ветвление от основной линии облегчает слияния, поскольку у двух ветвей будет общий предок, который не ветвится за ветвью за ветвями.
2. Развитие. Здесь разработчики проверяют код. Можно выделить несколько веток разработки, чтобы изолировать изменения с высоким риском от рутинных и обыденных.
3. Техническое обслуживание. Исправлены ошибки в существующей производственной среде.
4. Накопление. При объединении двух ветвей, один может не захотеть рисковать дестабилизацией магистрали. Так что разветвляйте основную линию, объединяйте ветви в накопитель и возвращайтесь к основной линии, как только все улажено.
5. Упаковка. Упаковка релиза происходит в упаковочных ветках. Это часто становится релизом и служит для изоляции релиза от разработки. См. Как бороться с нежелательными коммитами, которые нарушают длительные сборки релизов? например, где упаковка конфликтует с разработкой.

В вашем примере у вас есть каскадная магистраль (это проблема - она ​​усложняет слияние - что произойдет, если вы захотите объединить исправление для v1 в v2 и v3?), Ветвь dev, которая становится ветвью обслуживания ( смена политики, это проблема).

Хорошо, вы говорите, это здорово, но это было написано для перформанса, который является централизованным VCS - я использую DVCS.

Давайте посмотрим на модель git-flow и посмотрим, как она применяется.

Основная ветвь (синяя) - это ветвь релиза - для тегирования. Это не основная линия. Основной чертой является фактически развивающаяся ветвь (желтая). Ветви выпуска (зеленые) играют роль упаковки. Развитие с низким риском происходит в основном, развитие с высоким риском происходит в функциональных ветвях (розовый). В этой модели накопление осуществляется в ветви разработки. Техническое обслуживание считаются «исправлениями» красного цвета.

Хотя политики ролей не являются точными (у каждого продукта свой собственный жизненный цикл), они совпадают.

Это должно упростить вашу политику ветвления и упростить ее для всех участников.

Хотя вы пытались использовать отдельную ветку -prod с привратниками, похоже, что один репозиторий используется для фактической сборки. Если бы производственные сборки были сделаны только из производственного репозитория, доступного для записи только его привратником, то разработчики не смогли бы перейти на него. Это накладывает нагрузку на привратника, который только подтолкнет к производственному репо после проверки. Конечно, люди по-прежнему смогут вытаскивать из репо, когда это необходимо.

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

И, как правило, примените Occam's Razor: вся структура репо должна быть максимально простой, чтобы выполнять свою работу.

Смотрите также комментарий Шона.

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

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

Предложение @ andy256 относительно отдельного репозитория для prod, безусловно, поможет, но вам, возможно, придется рассмотреть возможность разделения работы по-разному или, возможно, упорядочить вещи так, чтобы никакой dev не работал над более чем одной веткой за данную неделю.

Похоже, вы определили одного из моих главных медведей. Большинство инструментов контроля версий - это как раз инструменты контроля версий. Они позволяют группе разработчиков работать с одним и тем же исходным каталогом, внося изменения и обрабатывая конфликты. На этом пути было несколько грубых краев, но cvs, subversion, git, mercural и т.д.

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

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

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

Сложная среда - это то, где у вас есть несколько команд, отвечающих за различные аспекты общего решения, выполняя внутренние выпуски для других команд. git-flow просто не способен решить такую ​​проблему.

Единственный способ, которым я видел эту работу, заключается в том, чтобы каждая группа отвечала за определение своих выпусков и контроль за изменением их зависимостей. Только потому, что команда A выпустила выпуск 1.3, команда B начинает использовать выпуск команды A только 1.3, когда команда B выбирает.

По сути, команда разработчиков определяет группы изменений, которые необходимо переместить, а разработчики, получающие изменения, определяют, когда они получают группу изменений.

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