Блог

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

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

Был ли у вас опыт выполнения этого раньше? Хорошо ли это сработало? Были ли у вас проблемы — какого рода проблемы?

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

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

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

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

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

Подробные сведения

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

1. Работа в одной ветке: Разработчики, работающие над слабо связанным или несвязанным кодом, могут относительно безопасно работать непосредственно в одной ветке разработки (или «Интеграции»). Исправления ошибок и неразрывные изменения прекрасно вписываются сюда (меньший риск серьезных регрессий, влияющих на других разработчиков). Сборки с непрерывной интеграцией и закрытые сборки — это две лучшие практики, которые снижают риск многих разработчиков, работающих в одной ветке. Примечание о переключении: Переключение функций можно использовать, чтобы в дальнейшем избежать необходимости ветвления, но убедитесь, что накладные расходы на тестирование / поддержание режима переключения не являются более рискованными, чем использование ветки.

2. Наборы полок: Используйте функцию вашей системы контроля версий для сохранения ожидающих изменений в прототипных ветвях, специфичных для разработчика. Разработчики, выполняющие регистрацию в TFS (Team Foundation Server), могут использовать наборы полок вместо личных ветвей (или множество ветвей микрофункций / задач), если они единственные, кому необходимо разработать и протестировать функцию перед регистрацией в ветке интеграции / разработки. Я полагаю, что другие системы контроля версий имеют аналогичные конструкции АНТИШАБЛОНА: локальные рабочие области автоматически обеспечивают временную изоляцию для каждого разработчика… но разработчикам необходимо часто / ежедневно проверять свои изменения где-нибудь в системе управления версиями, чтобы предотвратить риск потери дней работы только на локальном сервере.)

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

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

Пример сценария: Новая «крутая» функция нарушит существующую функциональность и сборки до завершения. Для совместной работы над одной кодовой базой также требуется, чтобы более 2 разработчиков работали над одной и той же кодовой базой (исключая возможность использования Shelveset). Владелец разработчика для «Cool» создает ветку с именем Cool1, затем разрабатывает и интегрирует первую версию функции. Протестируйте. Владелец разработчика отвечает за ежедневное объединение родительских изменений (максимум еженедельно). Подтвердите готовность к объединению (родительское объединение выполняется дочерним (FI), все приемочные тесты UT и core выполняются и по-прежнему проходят). Выполните слияние с родительской ветвью (RI), затем подтвердите работу в родительской ветви (все приемочные тесты UT и core пройдены), затем удалите ветвь функций Cool1 (очистка).
Протестируйте классную функцию более тщательно после объединения с веткой разработки / интеграции. (Ресурсы тестирования ограничены, поэтому избегайте полной тестовой среды для каждой ветви.) Исправления ошибок и тактические усовершенствования / рефакторинг для Cool would выполняются непосредственно в ветке разработки (использование наборов полок, когда назначенному разработчику требуется много дней для локальной разработки / тестирования перед регистрацией). Если позже потребуется серьезная доработка Cool (с участием нескольких разработчиков), создайте новую ветку Cool2.

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

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

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

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

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

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

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

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

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

Ветвление по функциям может быть эффективно выполнено в TFS, но, как и во всем остальном в dev, чем сложнее вы становитесь, тем больше накладных расходов вы несете.

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

С помощью git я работал над локальной веткой, создавая ветви, связанные с функцией / workitem. После завершения работы вы можете отправить ее в свой удаленный филиал. Затем из удаленной ветви вы отправите запрос на извлечение в свою ветку разработки / интеграции. Как только запрос на извлечение будет рассмотрен, рецензент объединит ветку PR с веткой dev. У меня это сработало очень хорошо.