Филиал по признаку - Преимущества/недостатки?

Ответ 1

Мы используем функцию branch by feature, и она работает очень хорошо для нас. Самое большое преимущество заключается в том, что функциональные команды знают, что то, над чем они работают, не влияет на другие функциональные команды, пока новая функция не будет интегрирована (в нашем случае Main).

Когда мы закончим с новой функцией (и ветвь была объединена с Main), мы переместим ветвь в папку History History. Это приводит к тому, что число ветвей (папок), которые разработчики должны смотреть на минимальное количество, должно содержать меньше.

В нашем случае никто не работает в Главном филиале. Все разработки выполняются в функциональной ветки. Начальная разработка (до первого выпуска в Production) выполняется в ветке разработки. После первой продажи в Production вся разработка выполняется в новой ветки Feature.

Ответ 2

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

ПОДРОБНОСТИ

Вот образец, который я нашел, чтобы сбалансировать производительность с безопасностью управления версиями (для команды ~ 25 разработчиков и ~ 3 тестировщика):

• Работа в той же ветке: Разработчики, работающие над слабосвязанным или несвязанным кодом, могут работать непосредственно в одной ветки Dev (или "Интеграция" ) относительно безопасно. Исправлены исправления и неразрывные изменения, которые хорошо подходят (ниже риск серьезных регрессий, влияющих на других разработчиков). Непрерывная интеграция и стробированные сборки - это две лучшие практики, которые уменьшают риск того, что многие разработчики будут работать в одной и той же отрасли. Toggle Примечание.. Переключатели функций могут использоваться, чтобы избежать необходимости ветвления, но убедитесь, что служебные данные для проверки/поддержания поведения переключения не являются более рискованными, чем использование ветки.

• Полки: Используйте функцию системы управления версиями для сохранения ожидающих изменений в прото-ветвях разработчика. Разработчики, подключающиеся к TFS (Team Foundation Server), могут использовать полки вместо личных веток (или многих веток с микрофункциями/задачами), если они являются единственными, кто должен разработать и протестировать эту функцию, прежде чем приступать к интеграции /dev, Я считаю, что другие системы контроля версий имеют аналогичные конструкции ANTIPATTERN: Локальная рабочая область автоматически обеспечивает временную изоляцию для каждого разработчика... но разработчики должны часто или часто проверять свои изменения в контроле источника, чтобы предотвратить риск потери дней + работы с локальным доступом.)

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

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

Пример сценария: Новая функция "Cool" нарушит существующую функциональность и строит до завершения. Для этого также требуется 2+ разработчиков для совместной работы на одной и той же базе кода (исключая возможность использования Shelveset). Владелец Dev для "Cool" Создает ветвь с именем Cool1, затем разверните и интегрируйте тест первой версии функции. Владелец Dev несет ответственность за слияние родительских изменений ежедневно (еженедельно в абсолютном большинстве). Подтвердите, что вы готовы к объединению (родительский слияние делает дочерний (FI), все UT и основные тесты приемки выполняются и продолжают проходить). Объедините с родительским (RI), затем подтвердите работу в родительской ветке (все тесты UT и Core Acceptance Tests пройдут), затем удалите ветвь функции Cool1 (очистка).
Протестируйте функцию Cool более тщательно после объединения с веткой dev/integration. (Ресурсы тестирования ограничены, поэтому избегайте полной тестовой среды для каждой ветки.) Исправления и тактические улучшения/рефакторинг для Cool будут выполняться непосредственно в ветке Dev (с использованием полки, когда назначенный разработчик требует много дней для локального dev/test перед регистрацией). Если позже потребуется большая (многопрофильная) переделка Cool, создайте новую ветвь Cool2.

TFS2010 move/rename Примечание: Изменено поведение и переименование TFS 2010 (из TFS 2008), чтобы сделать ходы и переименовать = "перейти к новому имени/местоположению, а затем пометить исходный элемент как удаленный". Это означает, что вы должны просто удалить неактивные ветки функций, если вы не хотите видеть их в исходном управлении\Dev\вместо того, чтобы переместить ветку в другую папку. Это также означает, что разработчики, которые разрешают просмотр удаленных папок, всегда будут видеть, как эти удаленные (или перемещенные или переименованные) ветки недолговечны как "призраки", которые могут стать загроможденными. (Как вы можете просмотреть историю или восстановить удаленный элемент.)

Ответ 3

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

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

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

Как только данная функция считается пройденной, желательно удалить переключатель и просто сделать его частью общего приложения.

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

Недавно я посетил конференцию, организованную Thoughtworks, где Мартин Фаулер обсуждал эту тему. В разговоре основное внимание уделялось непрерывной доставке и тому, как это может помочь преодолеть медленные и рискованные развертывания. См. http://www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops или просто выполните поиск для непрерывной доставки для получения дополнительной информации.

Ответ 4

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

Будьте осторожны с высоким оттоком, соединенными и общими частями вашего кода. Это будут области раздора.

Функция Branch by feature может быть эффективно реализована в TFS, но, как и в случае с чем-либо более сложным, вы получаете больше накладных расходов, которые вы понесли.

Ответ 5

Git лучше, чем TFS. Я использую git уже более 7 лет и до этого использовал TFS. Недавно я сменил свою работу, где мне нужно использовать TFS. Просто наличие ветки dev и все разработчики, работающие над одним и тем же разработчиком, не дают возможности для надлежащей проверки. Мне нравится, что в обзоре кода git есть формальный процесс.

С git я работал в локальной ветке, создавая ветки, связанные с функциями/рабочими. После того, как у вас есть работа, вы можете нажать ее на удаленную ветку. В удаленной ветке вы получите запрос на перенос в ветку dev/integration. После того, как запрос на извлечение будет рассмотрен, рецензент объединит PR-ветвь dev. Это очень сработало для меня.