Модульная 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 только для того, чтобы синхронизировать ваши сценарии сборки...

TeamBuild автоматически получает только элементы в папке сборки (в 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 только устанавливают свойства, по большей части; нет "настоящей" работы. Они охватывают свойства TeamBuild, которые я хочу параметризировать, а также другие, которые управляют работой моих пользовательских целей (реализованных в других местах).

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

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