Продвижение кода с помощью Subversion

Question

Я работаю над переносом нашей команды разработчиков на Subversion и улучшением структуры и процессов нашего хранилища. Мы в основном идем со стандартной настройкой соединительных линий / тегов. Изначально я планировал использовать стратегию веток релиза (Branch / 1.0, Branch / 2.0 и т. Д.), Но сейчас склоняюсь к модели продвижения кода (тестовая и производственная ветки). Это немного лучше и более интуитивно понятно, как работает наша команда, но релизы будут немного менее простыми: нам нужно, чтобы тестовая ветвь стала производственной. (Производственная ветвь всегда доступна для выпусков обслуживания, но ветвь тестирования не должна существовать между развертыванием одного выпуска и готовностью к тестированию следующего.)

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

а. Полностью объединить тестовую ветку с рабочей веткой, удалить тестовую ветку
б. Удалить ветку производства, скопировать тест в производство, удалить ветку теста
с. Удалить производственную ветку, переименовать тестовую ветку в производственную

Спасибо за любой совет!

Answer 1

first: опция b) и c) такие же в subversion, как и в subversion, переименования фактически копируются и удаляются.

Тем не менее, у вас есть только два варианта:

1. Полностью объединить тестовую ветку с рабочей веткой, удалить тестовую ветку

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

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

   Однако обычно вы можете сделать это с небольшим количеством накладных расходов

2. Удалить производственную ветку, переименовать тестовую ветку в рабочую

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

   Недостатки:

   Вы аннулируете все рабочие копии, которые указывали на тестовую ветку (которая стала производственной!)

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

Также имейте в виду, что вы можете не хотеть, чтобы все коммиты в тестовой ветке работали (зачем вы тестировали, если все идет хорошо?). Поэтому я настоятельно рекомендую вариант A

Answer 2

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

Answer 3

Ваши производственные филиалы должны оставаться нетронутыми. Назовите их по номеру выпуска. ProductName_Production_ {главная}. {Второстепенный}. {} Минор. При переходе от тестирования к производству вы создаете новую производственную ветку с номером последней версии. Удалите тестовую ветку, если хотите, но она может быть обработана таким же образом.

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

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

Answer 4

Почему вообще происходит миграция кода? Вместо этого постройте миграцию!

Уже более 4 лет мы просто использовали филиалы. Мы взяли ствол и сделали нашу первую ветку, которая называется RB-2013.07.0.x. Это ветвь релиза на июль 2013 года. Мы заблокировали грузовик, поэтому никто не мог внести в него изменения. Все изменения были внесены в RB-2013.07.0.x. После того, как был выпущен июльский выпуск, мы заблокировали RB-2013.07.0.x, поэтому в него больше нельзя вносить изменения.

Тем временем мы также создали ветку RB-2013.09.0.x, для сентябрьского выпуска, из Транка. Разработчики работали над выпуском в сентябре, работая над выпуском в июле.

После того, как июльская версия вышла в PROD, мы объединили RB-2013.07.0.x в RB-2013.09.0.x. Мы никогда не возвращались к Сундуку. Мы никогда ничего не переносили. И за более чем 4 года мы вообще никогда не теряли никакого кода, и, когда вы смотрели на проект, вы точно знали, для чего нужна ветка.

Если у вас есть проблема с продуктом (оперативное исправление), вы должны взять текущий выпуск продукта - скажем, RB-2013.07.0.x и создать ветку RB-2013.07.1.x, внести изменения, развернуть в prod заблокируйте ветвь и объедините ветвь с верхними ветвями - RB-2013.09.0.x. Таким образом, вы будете иметь все в курсе.

Помните, что при каждой сборке мы создавали тег и сохраняли его в каталоге TAGS.

В построенных нами сборках мы добавили номер редакции из SVN в последнюю часть номера сборки.
Сборки будут идти из dev, для тестирования, в UAT / pre-prod, а затем в prod. Если вы хотите узнать, какой код был в каждой сборке или ветви, перейдите в SVN и извлеките список журналов.

Answer 5

Я создаю тег из любой ветви или ствола для каждого выпуска.

• tag / 1.0_tc1
• tag / 1.0_tc2
• бирка / 1.0_rc1
• бирка / 1.0_ga

Если rc1 приемлем, вы просто помечаете его снова как 1.0_ga

Answer 6

На самом деле мы не различаем основную рабочую ветку и ветку тестирования на уровне контроля версий кода, но для меня это имеет смысл.

Я бы на самом деле пошел на такой подход, как

• основной
• тестовая ветка
  • тест
• производственная ветка (для них будет использоваться папка tag)
  • production1.0

Когда тест завершен, вы копируете его в новую папку / ветку production1.1.