Модульная TeamBuilds

Question

У меня есть 3 билда TFS (2 разработчика и 1 сертификат).

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

Проблема, с которой я столкнулся, заключается в том, что Team Build автоматически получает только элементы в папке сборки (в TeamBuildTypes). Я могу вставить код в процесс сборки, чтобы получить другие файлы, но к тому времени уже слишком поздно.

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

Я думал о добавлении его в рабочую область сборки, но затем он будет получен в цели Get Sources (что тоже слишком поздно).

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

Есть идеи?

Answer 1

В Team Build 2008 не существует «идеального» решения этой проблемы, ваш лучший вариант - поместить обычные вещи на машине сборки в $(MSBuildExtensionsPath), которая разрешается в C:\Program Files\MSBuild, а затем ссылаться на них.

Если ваши конфигурации сборки очень похожи, вы можете:

1. Укажите все ваши определения сборки в одну папку конфигурации.
2. Поместите общую логику сборки в TFSBuild.proj.
3. В нижней части TFSBuild.proj добавьте <Import Project="TFSBuild.$(BuildDefinitionName).proj" />.
4. Добавьте конфигурацию, которая варьируется между определениями сборки в TFSBuild. <BuildDefinitionName>.proj.

Answer 2

ваш лучший вариант - поместить обычные вещи на машине для сборки в $ (MSBuildExtensionsPath), который разрешается в C: \ Program Files \ MSBuild

Мне не нравится идея брать зависимость от "магических" локаций. В итоге вам понадобится 2-й процесс развертывания + QA только для того, чтобы синхронизировать ваши сценарии сборки ...

Team Build автоматически получает только элементы в папке сборки (в TeamBuildTypes).

Какая-то хромая, по общему признанию, но я не нашел это главным ограничением на практике. Вот упрощенный взгляд на мою папку TeamBuild:

$/TeamProject
   |- Dev
       |- Module1
       |- Module2
       ...
       Solution1.sln
       Solution2.sln
       |- TeamBuild
            |- 3rdparty
                MSBuild.Community.Tasks.dll
                MSBuild.Community.Tasks.targets
                RandomScriptOffTheWeb1.targets
                ...
            |- SrcSrv                
                srcsrv.ini
                ...
            |- SymStor
                dbghelp.dll
                ...
            Common.targets
            TFSBuild.proj
            TFSBuild.Common.targets
            TFSBuild.Config1.targets
            ...
            UtilityScript1.ps1
            ...
   |- Main           
       ...
       |- TeamBuild
       ...
   |- Release
       ...

Common.targets импортируется всеми файлами * .csproj (и т. Д.). Он импортирует все мои сторонние задачи, инициализирует различные глобальные свойства / элементы и устанавливает ссылочные пути.

TFSBuild.proj импортирует Common.targets, затем TFSBuild.proj, затем один из файлов конфигурации, используя $ (BuildDefinition). Таким образом, более конкретные всегда переопределяют задачи / свойства / и т. Д. Из менее конкретных файлов по мере необходимости. Тем не менее, этот короткий файл - единственное место, где я чувствую себя ограниченным: было бы намного лучше программно сопоставить имена сборок с именами файлов, но MSBuild не позволит мне сделать [декларативный] импорт зависимым от свойств, установленных в [runtime] целях, таких как .

TFSBuild.Config * .targets файлы только устанавливают свойства, по большей части; нет "настоящей" работы. Они охватывают свойства Team Build, которые я хочу параметризировать, а также другие, которые управляют работой моих пользовательских целей (реализованных в других местах).

TFSBuild.Common.targets - это самый длинный файл на порядок. Здесь я настраиваю все свойства Team Build с хорошими значениями по умолчанию, переопределяю цели, такие как AfterDropBuild, и определяю множество моих собственных пользовательских целей, которые выполняются условно на основе того, что установлено в файлах Config *.

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