Модульные TeamBuilds

У меня есть 3 сборки TFS (2 Dev и 1 Cert).

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

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

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

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

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

Любые идеи?


tfs msbuild build-automation tfsbuild
person Vaccano    schedule 10.06.2009    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

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

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

arrow_upward
3
arrow_downward

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

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

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

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

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

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

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

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

person Richard Berg    schedule 12.06.2009