Я не уверен, как вы попадаете в ситуацию, подобную той, которую вы описываете. Как были созданы 8.1-8.3? Как вы планируете справиться с 9,1 (или 10)?
«Звездные» конфигурации встречаются чаще:
- 9 - 9.0
D \ / 8.3
E - QA / 8.2
V / \ - 8 - 8.1
\ 8.0
Возможно, вам придется сделать одно или два дополнительных слияния на каждое исправление, но в целом это гораздо более гибко.
- Легко создавать новые ветви релизов в правильном месте в иерархии.
- Легко определять и применять правила для потока кода. (на этой схеме клише становится «объединить влево, скопировать вправо»)
- Все еще относительно легко обеспечить внесение изменений везде, где они нужны.
Обходной путь, к которому вы пришли через Rename, хорош. Я не могу придумать ничего лучшего, основываясь на существующей структуре.
* ответы на вопросы *
Из того, что я вижу здесь, 8 и 9 не являются действительно работающими ветвями и никогда не будут выпущены, верно?
Да.
Поскольку 8.0 не является ребенком 8.1, как вы получаете свои изменения с 8.0 в 8.1. Похоже, что для получения изменений от 8.0 до 8.1 вам нужно объединить их в 8, а затем обратно в 8.1. Но если это так, то вам также нужно объединить 8,2 изменений в 8, чтобы получить 8,3. Если это так, то что предотвращает случайное копирование изменений 8.2 в 8.1?
Ты прав, это не сработает. Я сделал предположение, что поддерживается только одна минорная версия каждой основной версии. Если бы вы нарисовали «звезду» более обобщенным образом, ветви промежуточного выпуска (8 и 9 в моем примере) представляют собой изоляцию. Не должно быть никаких параллельных изменений, происходящих внутри их области. Если основной версии # недостаточно, чтобы отделить активные от неактивных веток, вам понадобятся другие критерии для применения этой идеи.
Также в настоящее время мы работаем над 8.2, 8.3, 8.4 и 9 одновременно. Я не вижу пути слияния из любой версии 8 в какую-либо версию 9. Разве невозможно объединить из 8 в 9? Кроме того, что содержат QA и ветки разработки? Казалось бы, они могут иметь только последнюю версию, поэтому на этом рисунке они будут такими же, как 9?
Я обычно думаю о вещах, которые работают наоборот. Подавляющее большинство изменений вносятся непосредственно в ветки Dev, а затем медленно проталкиваются в среды интеграции / QA / UAT / Release с постепенно ужесточающимися стандартами качества. На моей диаграмме этот поток слева направо. Иногда вам может потребоваться исправить что-либо непосредственно в правой части ветви, например, если клиент обнаруживает проблему с высоким приоритетом в уже выпущенном продукте, но это исключение, и к нему следует относиться с должной осторожностью. С другой стороны, если это произойдет, то слияние справа налево может (и должно) происходить оптимистично, то есть рано и часто.
Если вы можете заранее определить, какие изменения происходят в каких выпусках, соответственно выделите ветви Dev. Другими словами, если у вас есть работа, которая, как вы знаете, не будет выполнена до 9.x, поместите ее в ветку, отличную от веток Dev с функциями 8.x. Таким образом, последний может безопасно выполнить полное «копирование-слияние» (без подбора вишни), поскольку их работа направлена правильно, гарантируя, что QA не будет потрачен впустую на код, который не подвергся интеграции с параллельными ветвями (или отделению от случайного 9.x зависимости) пока.
Самые правые ветви, где представлены актуальные выпуски, даже создавать не нужно, пока код не будет безвозвратно отклонен. Ответвление за релиз - это в основном сигнал о том, что разработка прекращается, и vNext официально запущен. С точки зрения SCM, он устанавливает односторонний барьер в потоке изменений, чтобы гарантировать, что старый код не приобретет новые зависимости (как в вашем вопросе о смешивании изменений 8.2 в 8.1).
Давайтепосмотрите на общую последовательность, которую я имел в виду, когда рисовал диаграмму. Для повторного использования рисунка выше я буду полагать, что вы поддерживаете только один выпуск 8.x и один выпуск 9.x.
- Создание веток Dev / QA от ствола (точные детали зависят от размера команды и зависимостей)
- Много работы происходит в ветках Dev
- Ветви, содержащие работу 8.x, начинают двигаться в нужном направлении по мере появления функций и соответствия стандартам качества
- Все ветви (включая ветви с функциями только для 9.x) принимают изменения от своих родительских ветвей рано и часто - на диаграмме QA является родительским элементом для всех, но то же самое верно, если там есть другой уровень косвенности
- После того, как последняя функция 8.x перешла в QA и прошла ее требования, создается ветка "8"
- Теперь ветки 9.x Dev могут безопасно отправлять код в QA, не беспокоясь о том, что эти изменения появятся в версии 8.x. Будущие слияния с 8 (и всеми детьми) выполняются только справа налево.
- 9.x код поступает в QA и выходит из него так же, как это делал 8.x: осторожные правые копии, нетерпеливые слияния влево.
- 10.x При желании можно создавать ветви Dev.
- Тем временем версия 8 находится в режиме окончательного исправления ошибок. Как только v8.0 полностью завершен, создается ветка 8.0. То же правило: допускается только слияние справа налево.
- Поскольку клиенты находят ошибки в 8.0, они могут быть исправлены несколькими способами.
- Непосредственно в ветке 8.0, затем сливается с 8 и обратно вокруг дерева. Это наименее подвержено ошибкам, но может раздражать, так как разработчики переключают контекст между 8.0 work и vNext.
- В 8, QA или даже в одной из (теперь исключительно 9.x / 10.x) веток Dev. Затем объединяются путем тщательного выбора нужного набора изменений вокруг дерева или путем необоснованного объединения. Это более вероятно вписывается в повседневный рабочий процесс для разработчиков, в первую очередь ориентированных на будущие выпуски, но несет определенный риск (и, следовательно, более высокую стоимость тестирования).
- Непосредственно в 8.0 и снова в Dev; TFS не участвует ни в каких слияниях. Как правило, это проще всего, когда изменение невелико и / или кодовые базы расходятся до такой степени, что сборка различий занимает больше времени, чем внесение двух независимых исправлений вручную.
- Когда вы собрали достаточно исправлений, чтобы оправдать незначительный выпуск, создайте ветку 8.1. Теперь 8.0 полностью доступен только для чтения, 8.1 подчиняется тем же правилам, что и 8.0 ранее, а 8 становится точкой сбора для потенциальных исправлений 8.2.
- Вернувшись на сторону разработки дерева, последнее исправление 9.x успешно проходит через QA. Вы создаете ветку «9», прокладывая путь для разработки 10.x.
Это явно не точный шаблон для вас. Для одновременного развития трех версий 8.x необходимо основать решение на шаге № 5 на чем-то ином, чем просто номер версии. Я не знаю достаточно о вашем бизнесе, чтобы сказать вам, что это должно быть.
Кроме того, вы не сможете так легко отделить разработку функций 8.x от разработки 9.x. Планы меняются. Если функция 9.x будет перемещена до версии 8.x, вам, вероятно, придется выбрать вишню из ее ветви Dev. Если функция 8.x будет перенаправлена на 9.x до того, как будет создана ветка "8", у вас есть тяжелая работа в будущем - ни одна структура ветви не решит это.
Точно так же шаги # 5-6 зависят от вещей, заканчивающихся в последовательности. Это работает лучше всего, когда 8.x достигает «почти готового» состояния (как представлено RHS дерева) примерно в то же время, когда ветви 9.x должны начать делиться своей работой друг с другом и с QA. Опять же, реальность часто диктует иное. Для некоторых решение тривиально: команды 9.x могут продвигать и принимать код, не затрагивая основной ствол, создавая уровень косвенности. (На диаграмме это будет ветвь слева от «QA», которая является общим родителем некоторых ветвей Dev.)
Но если я понимаю вашу ситуацию, разработка функций может быть разделена на 4 или более этапов будущих выпусков. Если ваш код не является чрезвычайно модульным, и вы не чувствуете себя комфортно при слиянии вишневого пика, вам может потребоваться «более густое» ветвистое дерево. Представьте, что у «8» и «9» выше есть свой собственный независимый массив веток Dev / QA, питающих их. Или, насколько я знаю, каждая второстепенная версия будет нуждаться в собственной миниатюрной модели продвижения Dev-QA-Release внутри своей части дерева. Зависит от того, как вы в конечном итоге сегментируете области активного выпуска друг от друга. В любом случае, наличие нескольких эффективных «стволов» устраняет потенциальный конфликт планирования из-за использования ветви QA, за счет (a) дополнительных шагов для распространения изменений 8.x до секции 9.x дерева (b) явная сложность. Я не фанат такого подхода и надеюсь, что вы можете избежать этого.
Хорошо, хватит на сегодня. Дальнейшее чтение:
Введение в стандартную модель Dev-QA-Release, которую я все время более или менее предполагал:
Презентация о том, почему вы хотите расположить свои ветви так, чтобы код обычно перетекал из неустойчивой «стороны» дерева в устойчивую «сторону» (в ее слайде в PDF-заметке он вверх / вниз вместо левого / правого); почему правила слияния в каждом направлении очень разные
Информационные документы, поддерживающие идею о том, что сохранение одной основной линии (например, "QA" на моей диаграмме) лучше, чем позволить ветвям релиза каскадно отделяться друг от друга.