TFS build-server построить ветку?

Ответ 1

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

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

/EDIT/

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

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

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

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

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

Ответ 2

У меня также возникла эта проблема при запуске сборки из ветки в TFS 2010. TFS сообщала, что "Нет сопоставления рабочих папок для $/Main/Product.sln". Решение оказалось для редактирования определения сборки следующим образом (я использую шаблон процесса построения шаблона "Default Template" - я не пробовал это с помощью настраиваемого шаблона):

• Перейдите в раздел Process/tab определения сборки.
• Развернуть 1. Требуется и искать проекты для сборки. Убедитесь, что эта запись указывает на файл решения внутри ветки, которую вы создаете.
• Развернуть 2. Basic и найдите автоматические тесты. Направьте это на правильный файл настроек теста в построенной ветке.

Ответ 3

ОК, результаты в... Я нашел обходное решение.

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

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

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

• $/NewFeature → c:\Main

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

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

Решение №2 должно сделать это:

• $/Main → c:\IgnoreThisFolder
• $/NewFeature → c:\Main

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

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

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

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

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

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

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

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

Ответ 4

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

• Настройки источника - укажите местоположение вашего нового проекта.
• Процесс - (Это иногда занимает некоторое время, чтобы загрузить, так что будьте терпеливы). В разделе "Обязательно" измените местоположение "элементы для сборки" на новое решение.

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

Ответ 5

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

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

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

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

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

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

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

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

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

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

Ответ 6

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