TFS 2008: вопросы об автоматических сборках, метках и общем управлении версиями

Question

сначала немного фона ...

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

Вероятно, мы пойдем с этим так: когда мы готовимся к выпуску, мы снимаем ветку с dev и называем ее 1.x. Это будет тестовая ветка: мы тестируем ее, исправляем (затем объединяем обратно с dev), тестируем еще несколько раз, когда, когда все будет хорошо, мы берем другую ветку из ветки 1.x и вызываем ее 1.0. Именно эта ветвь развернута в производство. Все исправления в рабочей среде будут внесены в 1.x, протестированы, а затем будет создана новая ветка 1.1.

Моя проблема связана с тестированием ветки 1.x. Перед тестированием ветка будет заблокирована по понятным причинам. Моя проблема в том, что QA требует, чтобы раунд тестирования проводился против «номера версии», а в случае неудачи следующий раунд тестирования был бы против нового «номера версии». Мы, разработчики, хотим связать «номер версии» с выпуском, и тестирование может выполнить итерацию по этой версии ... поэтому здесь есть конфликт.

Моя первая мысль - использовать номер сборки в качестве момента времени, с которым тестируется код. Когда приходит время представить новую версию для тестирования, ветка 1.x снова блокируется, и сборка запускается, и генерируемый номер VSTS становится «условием выпуска 1 для v1.0». Сопоставление RC со сборкой мы можем сделать вручную в электронной таблице ...

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

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

Полагаю, меня смущает вопрос о том, где наборы изменений, номера / имена сборок и метки совпадают ...

Это широкий вопрос, но он один из тех, где я не уверен на 100%, что спросить. Любая помощь приветствуется.

Answer 1

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

То, что вы прочитали, правильно. В случае TFS (в отличие, скажем, от SourceSafe), каждое действие сервера представляет собой «известный момент времени», на который позже можно ссылаться. Вы можете понять, что я имею в виду, выполнив Get Specific Version... и просмотрев раскрывающийся список Version: в TFS 2005 я вижу соответствующие значения Changeset, Date, Label. Теперь, как вы правильно сказали, каждая сборка автоматически создает метку. Это означает, что в любое время в будущем будет возможно получить код точно так же, как это было после любого данного набора изменений; в любой данный день; и когда была применена какая-либо конкретная метка, в том числе когда была выполнена какая-либо сборка.

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

Answer 2

Ваша ветвь 1.x - это консолидация ветвь , которая будет содержать множество дополнительных небольших эволюций.
Блокировка ветки не является ответом.

Установка метки (специально названной «для теста QA» и заблокированной для того, чтобы не иметь возможности перемещать эту метку) - это обычный способ сообщить команде QA, что они могут создать свое собственное рабочее пространство и получить эту точную метку.
Затем они могут начать свои тесты против кода.
Создание метки после каждой сборки не всегда практично, поскольку не каждая сборка предназначена для тестирования QA.