TFS build-сервер сборка ветки?

Question

У нас есть проект TFS 2008 с двумя ветвями («Main» и «NewFeature»). Каждый является полной, независимой «копией» (вариантом) исходного кода.

Изменяя сопоставления рабочей области, мы можем сопоставить любой вариант с нашими локальными ПК и без проблем работать с обеими ветвями.

Однако, если я настроил сопоставления для переключения нашего сервера сборки на ветку NewFeature (которая должна просто поменяться местами в исходном коде NewFeature без каких-либо изменений в отношении сервера сборки), я получаю ошибки: *

There is no working folder mapping for $/Main/Product.sln

т.е. когда он строится из ветки NewFeature, что-то все еще ищет в ветке Main , хотя в исходном коде нет ссылок на эту ветку. Кажется, он кеширует какую-то ссылку на Main?!

Я сделал полностью чистую сборку (удалил папку сборки с сервера и запустил сборку с помощью / p: ForceGet = true, чтобы убедиться, что сопоставление сброшено на сервер, и на сервере нет файлов, которые может кэшировать привязки рабочей области), но это не помогает.

Есть предложения?

Answer 1

У меня также была эта проблема при запуске сборки из ветки в TFS 2010. TFS сообщала, что «Нет сопоставления рабочей папки для $ / Main / Product.sln» следующим образом (я использую шаблон процесса сборки «Шаблон по умолчанию» - я не пробовал это с пользовательским шаблоном):

1. Перейдите в раздел / вкладку Процесс определения сборки.
2. Развернуть 1. Обязательно и ищите проектов для сборки . Убедитесь, что эта запись указывает на файл решения внутри создаваемой вами ветви.
3. Развернуть 2. Basic и ищите Автоматизированные тесты . Укажите правильный файл настроек теста в создаваемой ветви.

Answer 2

Убедитесь, что:

• $ (SolutionToBuild) использует относительный путь при ссылке на Product.sln
• относительный путь между $ / NewFeature /.../ TFSBuild.proj и $ / NewFeature / Product.sln такой же, как в основной ветви.

/ РЕДАКТИРОВАТЬ /

Обратите внимание, однако, что не важно, чтобы $ / Main и $ / Branches / Feature находились на одном уровне в древовидной иерархии. Не должен иметь значения и локальный путь на сервере сборки. * Все, что имеет значение, это то, что находится под каждой веткой. Если содержимое внутренне согласовано, то все ваши существующие сценарии сборки должны работать без изменений.

Конкретные примеры того, как мне нравится связывать все воедино, см. В моих прошлых ответах, например ::

.

• Модульные TeamBuilds
• Управление SDLC для сценариев сборки TFS
• Где разместить проект моей базы данных в TFS?
• Как вы разделяете внешние зависимости между решениями Visual Studio?

Мой путь не единственный, но я могу засвидетельствовать, что он работает лучше, чем все другие варианты, с которыми я столкнулся за эти годы:)

* Честно говоря, попытка микроуправления Team Build может стать намного более болезненной, чем предлагаемая реструктуризация ваших скриптов MSBuild. Для надежности вы должны поместить ваши настройки tfsbuildservice.exe.config под управление версиями где-нибудь ... если у вас есть> 1 сервер сборки (или, возможно, в будущем), то вам необходимо рассмотреть стратегию развертывания изменений. ... вам нужен мета-SCM-процесс для управления процессом SCM!

Answer 3

ОК, результаты получены - я нашел обходной путь.

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

Итак, если у меня есть Main и NewFeature, я хочу разархивировать Main и отобразить NewFeature на своем месте (т.е. использовать «c: \ Main» на сервере сборки и просто изменить исходный код, который там появляется)

Решение # 1 (самое простое, очевидное и логичное решение) заключается в использовании этих отображений:

• $ / NewFeature -> c: \ Main

Ожидаемый результат: структура кода NewFeature просто заменяет Main, а сервер сборки не знает, что он находится в другой ветке.

Фактический результат: ошибка с ошибкой «вы не отобразили $ / Main, даже если вы ее не используете».

Решение № 2 заключается в следующем:

• $ / Main -> c: \ IgnoreThisFolder
• $ / NewFeature -> c: \ Main

Это работает (оно подавляет предупреждение и, таким образом, позволяет сборке продолжать работу с MSBuild, не зная, что он строит в ветке). Однако это ужасно, и сборка получает весь исходный код ветки Main без необходимости.

Решение № 3 (не проверено, слишком дорого, чтобы попробовать, если я не знаю, что оно будет работать намного лучше, чем # 2):

• Переместите весь исходный код (из $ / Main, $ / Branches / Feature) в $ / Branches / Main и $ / Branches / Feature, чтобы получить согласованную глубину иерархии, и перепишите сценарий MSBuild для работы с этими новыми путями. .

• Надеюсь, что тогда я смогу отобразить только нужную мне ветку и отредактировать TFSBuild.proj, чтобы перенаправить ее на эту ветку.

  (Изменить: Да, это работает хорошо. Теперь мы реорганизовали всю структуру кода, чтобы все (все ветви) находились под общим корнем в одном командном проекте, и ветвление / построение больше не является проблемой - сейчас легко сделать все, что нам нужно. Хитрость заключается в том, чтобы вставить корневую папку в иерархию, чтобы вы могли выполнять ветвление на любом уровне. Я добавил небольшую настройку в скрипт сборки, чтобы мы могли передать ветку построить как параметр для MSBuild, так что теперь легко построить любой вариант. Любые ветви, над которыми мы не хотим работать, могут быть просто замаскированы, а сервер сборки остается счастливым.)

Резюме Все эти решения (если использовать технический термин) отстой. Вы должны переназначить рабочее пространство (в этом случае это не просто: требуется 9 записей сопоставления, так что это подвержено ошибкам и утомительно), отредактируйте TFSBuild.proj, удалите весь исходный код и запустите сборку с / p: ForceGet = true для переключения сборки между ветвями. Так что переключение веток занимает около часа. Невероятно - это займет максимум несколько минут!

Я понимаю, что наш проект далек от идеальной настройки, но я не могу поверить, что переход в TFS должен быть таким сложным (это было очень просто в SourceSafe, Accurev и Perforce, так почему в TFS так больно ?).

Как все остальные организуют свои филиалы TFS? Как вы переключаете разработчиков между ветками? Как вы переключаете серверные сборки между ветками? Неужели это так больно?

Answer 4

Когда вы редактируете определение сборки, есть два места, которые нужно изменить.

1. Настройки источника - укажите местоположение вашего нового проекта
2. Процесс - (иногда требуется некоторое время для загрузки, поэтому наберитесь терпения) В поле «Требуется» измените местоположение «элементы для сборки» на новое решение.

Надеюсь, это поможет.

Answer 5

Я получил эту ошибку, и все, что я могу понять, это то, что определение испортилось или что-то в этом роде. Я просто переделал весь процесс (заново добавил решение, которое пытался построить), переназначил рабочие пространства, и он снова начал работать. НТН.

Answer 6

Новое обновление:

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

В TFSBuild.proj путь был основан на $ (BuildProjectFolderPath). Этот путь преобразуется в на стороне сервера (путь управления исходным кодом), например $ / Main, а не в локальный путь (D: \ ServerBuildFolder \ Main).

К сожалению, по историческим причинам наш исходный код разделен на несколько командных проектов, что означает, что одна «ветвь» фрагментирована на несколько разветвленных папок в Source Control (то есть $ / Main / Code и $ / Libraries / Code. Вы можете создать ветку, которая содержит $ / Main и $ / Libraries). Таким образом, мы должны собрать эти разрозненные фрагменты из Source Control обратно в последовательную иерархию, используя сопоставления рабочей области.

Это означает, что Ричард был на месте - относительный путь от файла TFSBuild.proj к файлу .sln был неверным, поскольку MSBuild / TFS предполагает, что .sln находится в той же иерархии командного проекта и управления исходным кодом (поэтому искал $ / Main / Libraries.sln вместо $ / Libraries / Libraries.sln).

Решение простое: я заменил $ (BuildProjectFolderPath) на локальный путь (например, D: \ ServerBuildFolder \ Main) для файлов, чтобы относительная ссылка была разрешена в «локальном пространстве» (после применения сопоставлений). ), и MSBuild теперь работает без проблем.

Мораль этой истории: 1) НИКОГДА не используйте более одного командного проекта, если есть вероятность, что вы когда-нибудь захотите иметь какую-либо ссылку между этими кодами. Не думайте, что новый командный проект предложит какое-то безболезненное логическое различие между приложениями / библиотеками. Дополнительные проекты оказались просто кошмаром администрации - множество дополнительных проблем для абсолютно нулевой выгоды. (Это все одна большая общая куча под капотом, поэтому все рабочие элементы и папки управления исходным кодом все еще видны во всех проектах (!), Но он добавляет несколько кирпичных стен, которые делают межпроектные ссылки очень проблематичными)

2) Всегда создавайте одну папку корневого уровня в вашем исходном элементе управления Team Project, а затем помещайте все остальное в эту папку. например Для проекта "$ / Main" создайте "$ / Main / Root" и затем поместите все из исходной иерархии в Root.

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

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