Мой совет - держать вещи как можно проще.ИМХО главные вещи, которых следует избегать:
- Сложность смущает людей.Чем больше сложностей, тем больше времени требуется для обработки, тем больше слияний вы делаете и тем больше ошибок допускаете.Если вам не нужен процесс , то удалите его.
- Если вы работаете с кодом в ветке, то в будущем вам обязательно потребуется объединить код.Чем дольше ветки живут до слияния, тем труднее и трудоемче становится объединение.
- Объединение иерархии ветвей друг с другом приводит к необходимости слияния на нескольких уровнях для возврата кода в ветку devЭто отнимает много времени, чтобы перенести изменение из внешней ветви в основную кодовую базу.
Так что вам определенно следует использовать ветвление для поддержки ваших потребностей разработчика, но постарайтесь сделать вашу схему такой простой, каквозможно.
Мы используем аналогичный, но более простой подход к вашему.То есть:
- Мы работаем над веткой Dev.Ежедневные сборки выходят из этой ветки для непрерывного контроля качества.
- Когда требуется релиз "заморозка кода", создается ветка Release.Исправление может быть сделано в любой ветке, но если требуется для выпуска, оно всегда немедленно объединяется, чтобы синхронизировать dev и release.Мы стараемся не допустить, чтобы выпуски расходились с основной веткой вообще, если это возможно.У нас никогда не бывает более одной активной ветки релиза за один раз.
- Когда разрабатываются небольшие функции или когда функции можно разрабатывать, не становясь «включенными» в приложении или иным образом влияя на стабильность кода, мы продолжаемразработать код в ветке Dev.Например, мы можем использовать условие #if, чтобы отключить код до тех пор, пока не будет безопасно «активировать» в ежедневных тестовых сборках.Это сводит к минимуму необходимость ветвления.
- Когда разрабатывается большая функция, которая потенциально может нарушить ветку Dev, мы работаем над отдельной веткой Feature.Мы пытаемся спланировать функцию, чтобы минимизировать время, в течение которого ветвям функции / dev позволено сосуществовать, и, если возможно, прекратить работу разработчиков над смежными областями кода во время разработки функции, чтобы минимизировать проблемы слияния после завершения функции.Если между выпусками разрабатываются возможные функции, чтобы минимизировать перекрытие (число параллельных ветвей).
Наши другие ключевые стратегии:
Использовать непрерывную интеграцию,Модульные тесты, регрессионные тесты, закрытые проверки и непрерывное тестирование для обеспечения максимальной стабильности ветки Dev.Наша цель состоит в том, чтобы любая ежедневная сборка «была» достаточно хороша, чтобы доставлять ее непосредственно клиенту.В действительности бывают периодические короткие периоды (несколько дней), когда эта стабильность теряется, но большую часть времени, когда это происходит, мы все еще находимся в течение нескольких дней с выпуском сборки.
Отложите создание веток, пока не понадобитсяВ TFS вы можете задним числом создать ветку из любой точки в истории кодовой базы.Поэтому, когда мы готовы запустить ветку релиза, мы фактически не создаем ветку, а просто отправляем текущую сборку релиза в отдел QA для тестирования.Если они довольны качеством этой сборки, она предоставляется покупателям без создания филиала.Только когда нам нужно исправить ошибку для этого релиза, мы фактически создаем ветку (с момента, когда был создан оригинальный релиз-кандидат, поэтому мы знаем, что он начинается с хорошо протестированного кодаснимок) и несут (небольшие) расходы, которые влекут за собой.
В качестве примечания, мы также попробовали ветку Dev с gated checkins для ветки QA с gated checkins для ветки Release, но это работало плохо (в первую очередь мы обнаружили, что это добавило значительные издержки ко всей разработке. Нам нравится проверятьчасто, и два дополнительных шага тестирования и слияния для каждой регистрации дороги. В худших случаях, если вы удаляете, перемещаете или переименовываете файлы в TFS, это становится очень ненадежным, и даже простые слияния заканчиваются неудачей - это трудно и занимает много времени для сортировкиМы решили, что объединение в TFS все еще не является легким и достаточно надежным для поддержки такого подхода, если вы не готовы тратить много времени на управление филиалами. С другой стороны, если разработчики осторожны с их регистрациями,Намного меньше необходимости в таком «строгом» подходе, поэтому мы вернулись к описанному выше легковесному подходу, который увеличивает риски, но сводит к минимуму необходимость объединения - для нас (с небольшой и дисциплинированной / компетентной командой) этот подход работает лучше.