Подходы контроля версий в Scrum

Недавно с моими коллегами мы обсуждали, как организовать контроль версий в проекте Scrum. Более конкретно, критерии создания веток (для каждого разработчика, для каждой задачи, для истории, для Sprint?) И методы интеграции.

Мое мнение состояло в том, что для его удобного способа создать ветку для каждой пользовательской истории, чтобы вы могли интегрировать каждую Историю в освобождаемую магистраль после ее завершения, а также позволяет всегда иметь "поставляемую версию", приложения в любой момент.

Итак, если история не может быть завершена, ее можно просто оставить без внимания и не скомпрометировать выпуск спринта. (Что касается централизованного инструмента, может быть, если вы используете распределенный, соображения будут разными)

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

Конечно, мы все используем git ', поэтому у нас всегда есть локальная ветвь, над которой мы работаем, и мы довольно хорошо синхронизировались с мастером достаточно часто, чтобы избежать крупных сбоев и редко, чтобы не оставить бесполезный/неиспользуемый код в главной ветке.

Кроме этого, мы делаем ветвь по-умолчанию (PDF). Я также написал немного больше о том, как мы делаем git здесь.

Ответ 4

Это очень интересная тема.

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

Вы можете увидеть, как это выглядит на следующей диаграмме:

Это упрощает процесс поощрения экспертных обзоров, поскольку команда может проверять, что было изменено в задаче (ветке), даже когда разработчики решили сделать много промежуточных коммитов (что очень хорошая практика!)

Здесь может быть полезно несколько ссылок ниже:

Ответ 5

Я бы использовал одну ветвь для выпуска и использовал Continuous Integration, чтобы одна история пользователя повреждала остальные.

Ответ 6

Единственное изменение, которое вы должны сделать для вашей исходной системы управления версиями, - это интегрировать его с системой непрерывной интеграции (например, TeamCity или CruiseControl.NET).

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

Ответ 7

Я не вижу, как ветка на каждую функцию может сделать вас более подвижным или худым. Стоимость управления веткими слишком высока. Я бы сказал, что если вы чувствуете, что вам нужна ветка для каждой функции, ваши истории слишком велики. История должна быть завершена следующей схваткой, а если нет, то, конечно, следующей. Поэтому, если ветвь существует только в течение 1-2 дней, я не вижу, как она может быть полезной или ее стоимость погашена. Для многих людей очень важно работать над историей, поэтому я иногда использую ветвь dev для разработчиков, чтобы работать, чтобы они могли объединять код. Много раз в день при работе над одной и той же историей без развертывания кода для тестирования (основная ветка), В идеале у вас было бы так мало историй, и они были бы настолько быстрыми, что вам понадобится только главный филиал, и никто другой.