Какой должна быть «ствольная» разработка или релиз

Question

У меня есть неудачная возможность контроля источников через Borland StarTeam. К сожалению, он делает очень мало вещей, и одной из его главных слабостей является управление взглядами. Я люблю SVN и пришел из SVN мышления. Наша проблема - постпроизводственный выпуск, мы проводим бесчисленные часы, объединяя изменения в среду «поддержки производства».

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

Текущая настройка

• Product.1.0 (TRUNK, текущий производственный код и на этом уровне ожидающие исправления ошибок)
  • Product.2.0 (все проверенные соединительные линии проверяются, а затем выпускаются в следующем производственном цикле, в этом представлении происходит много изменений)

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

• Производство
  • Production.2.0.SP.1

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

Answer 1

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

Большая картинка

Хорошо, теперь я прошел довольно подробный пример того, как использовать этот шаблон. Теперь давайте вернемся немного назад и посмотрим на общую картину.

В основной модели ветвь называется кодовой линией (фактически ветвь считается реализацией кодовой линии). Иногда это называют потоками.

Родитель кодовой строки (то есть кодовая строка, из которой она возникла) называется ее базовой линией. Mainline - это кодовая строка, которая не имеет базовой линии.

Итак, в приведенных выше примерах мы можем заключить, что:

• Хобот - это наша магистраль. У него нет родительского права?
• Все остальные кодовые строки (выпуск 1.0, работа команды A, работа команды B) имеют транк в качестве базовой линии.

Вот более сложный пример:

Эта картинка говорит нам, что:

• Создана кодовая линия проекта X от основной линии. Проект сейчас завершено, поэтому ветка закрыта.
• Команда A имеет активную рабочую ветку, которая был порожден от основной линии.
• Команда А также имеет постоянный всплеск, который был порожденный из рабочей ветки.
• ветка выпуска 2.3 закрыта, т.к. 2.3 больше не используется и не будет поддерживаться.

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

• Стабильная кодовая линия стабильна, тщательно протестированы, редко меняются и близок к выпуску.
• Мягкая кодовая строка нестабильна, едва протестирована, часто меняется, и далеко релиз.

При нанесении кодовых линий, фирменных кодовых линий ветвь вверх и мягкие коды ветвь вниз. Итак, глядя на На картинке выше можно сделать вывод, что:

• Релиз 2.3 более устойчив, чем Магистральный.
• Team A работа мягче чем основная линия.
• Спайк команды А мягче, чем работа команды А.

Подведем итог:

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

Я настоятельно рекомендую прочитать всю статью.

Answer 2

Я согласен с вашим подходом и подходом Криса Камински. Мы используем StarTeam, и это то, как мы его используем. Представление «Подсказка» или «Главное» в каждом проекте является текущей линией разработки (в терминах StarTeam это представление по умолчанию, имя которого совпадает с именем проекта). Каждый раз, когда мы собираемся на основе этого представления, наш сервер сборки создает метку сборки. Выпуск сделан с определенной меткой сборки.

Затем мы создадим новое представление для этой метки в качестве ветви выпуска выпуска, а затем любые исправления ошибок в выпуске будут применены к этому представлению (независимо от того, выполняются ли исправления ошибок в представлении Tip и объединяются с ответвлением или наоборот). Версия не имеет значения, если они объединены с основным представлением "Разработка").

Кроме того, если у нас есть конкретный проект, который будет работать долго и не будет завершен до следующего обычного производственного выпуска, мы сделаем ветвление в представлении «Подсказка» с настройкой «Ветвь при изменении». Это определенно не идеально, так как после его завершения должно быть выполнено много слияний, но оно не позволяет этому коду выйти за пределы основной линии разработки и гарантирует, что оно не может случайно оказаться в производственном выпуске. Мы пытаемся ограничить эти типы проектов, но иногда деловые люди диктуют их.

Эта установка очень хорошо сработала для нас, и, кажется, новичкам легко понять и работать с ней.

Answer 3

Вот мой общий совет по структурированию потоков сборки:

+HEAD - master -> current development 
+ tags
   + version1 
   + version1.sp1 
   + version1.sp2 
   + version2
+ branches
   + version1.sp2.fixes <- at some point, this will get promoted to version1.sp3 
   + version2.fixes <- at some point, this will get promoted to version2.sp1 
   + version2.nix.feature1 <- this is your (nix's) private version2.feature branch 
   + master.nix.feature2  <- this is your (nix's) private new development feature branch.

По сути, вы НИКОГДА не фиксируете напрямую в .fixes или в основной ветке - это делает только процесс интеграции.

Во всяком случае, практически любой инструмент управления версиями будет поддерживать эту модель.