Как перейти от сложной ветвящейся реальности к модели с одной ветвью?

В крупных организациях использование методологии водопада обычно приводит к очень сложным ветвящимся структурам (aka branch spagetti ).

Какие стратегии ветвления можно использовать для перехода от сложной реальности ветвления к модели с одной ветвью, такой как разработка на основе магистрали?

Обновить:

Для пояснения вопрос касается самой миграции / перехода , а не методологий до и после, которые довольно понятны.

На самом деле этого не может быть: «Сегодня на EOB мы все еще с водопадом, у которого миллионы ветвей, но завтра, во-первых, мы переключимся на магистральный одноканальный CI».

Поскольку вы упоминаете водопад, я понимаю, что многочисленные ветки, на которые вы ссылаетесь, являются функциональными ветвями, а не ветвями обслуживания.

В этой настройке я также предполагаю, что эти ветви создаются в соответствии с планом водопада, который пытается минимизировать конфликты. Это подразумевает, что целью разработки является производство нескольких различных продуктов. При использовании модели разработки с одной ветвью важно также работать с одним продуктом. Если несколько продуктов разрабатываются одновременно в модели разработки с одной ветвью, это эффективно «склеивает» версии этих продуктов, так что в версии a репозитория мы можем иметь исправный продукт X и продукт с ошибками Y , тогда как в версии b продукт X имеет регрессию, а Y исправление ошибки, но у нас нет версии, где X иУ здоровы. Такая ситуация заставит нас рассматривать X и Y как разработанные в различных репозиториях, что является намеком на то, что они должны быть.

Поэтому первые шаги должны выполнить разделение хранилища :

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

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

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

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

4. Внедрить методы программирования, помогающие развитию кратковременных ветвей. Кратковременные ответвления являются важнейшим аспектом всех методологий с одним ответвлением. Одна из их целей - сократить время, затрачиваемое на слияние и отладку долгоживущих веток. Популярной техникой является введение «флагов возможностей», когда «фабрика» использует флаг конфигурации для создания исторической версии объекта или новой, первоначально частично разработанной, версии этого объекта.

5. К настоящему времени у вас есть миллионы репозиториев с несколькими ветвями в каждой, и вы можете нажать кнопку «мы глобально применяем дисциплину разработки на основе ствола», не видя, как оригинальная гора веток-спагетти рушится на стволе.

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

При переходе от чего-то к чему-то еще нужно определить только две вещи:

1. Какова ваша цель
2. Как добраться (план миграции)

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

Скорее всего, все филиалы, которые у вас есть, служат или послужили цели. Без четко определенного целевого процесса люди будут продолжать делать то, что им выгодно, так, как им удобно (и это правильно).

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

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

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

Вы можете начать с «самых больших» или более важных веток. Например: «отныне master должен всегда находиться в состоянии, которое будет развернуто в prod, а ветка dev должна всегда компилироваться» (или какими-либо другими правилами). Затем принудительно установите ветки версий (выпусков). После этого принудительно используйте функциональные ветви. После этого наложите код на ветку версии, если это имеет смысл.

DevOps - это общение, открытость и эффективность. Эти понятия необходимо помнить и распространять на протяжении всего процесса.

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

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

На самом деле очень просто преобразовать многоразветвленный репозиторий Hydra в единую разветвленную модель.

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

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

Вы можете следовать этой простой схеме, чтобы начать:

1. Создайте копию своей основной / внешней ветки и назовите ее temp_master
2. Найдите ветку с наибольшим расхождением от мастера / ствола.
3. Определите, нужно ли хранить, архивировать или удалять ветку.
   1. Если это необходимо сохранить, перейдите к шагу 4.
   2. Если его необходимо удалить или заархивировать, удалите и заархивируйте его, а затем вернитесь к шагу 2.
4. Повторите шаг 2, чтобы найти следующую ветвь с наименьшей дивергенцией.
5. Объедините две ветви, найденные в шаге 2 и шаге 3, разрешив все конфликты.
6. Слейте эти две ветви в свою temp_masterветку.
7. Протестируйте код в коде temp_master, чтобы убедиться, что он компилируется, собирается и запускает любые другие автоматические тесты, которые у вас есть для здравомыслия.
   1. Если какие-либо тесты не пройдены, вернитесь, выясните причину и исправьте их, а затем повторите процесс.
   2. Если тесты все еще не пройдены, выберите две разные ветви для работы.
8. Повторяйте шаги 2 - 7, пока у вас не останется только две ветви: ваш мастер / ствол и temp_master.
9. Наконец, объединитесь temp_masterв master / trunk и живите с вашей новой моделью с одной веткой.

Для крупных организаций с типичным 4-недельным циклом спринта предпочтительным является подход Git-Flow , поскольку вы получаете преимущество ветки Feature. Мастер-готовая ветвь всегда готова к развертыванию. Кроме того, главная ветвь остается чистой от нежелательных коммитов, выполняя два цикла фиксации (от функции до Developи Developветвь). освоить).

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