Как связать сборки TFS?

У меня есть сценарий, когда я хочу вызывать одну сборку TFS из другой, первая делает сборку, а вторая - организует. Это позволит мне выполнять несколько пользовательских настроек для одного и того же решения.

Я знаю, я могу выполнить это с задачей exec во второй сборке и вызвать tfsbuild.exe для очереди сборки из первого определения сборки. Но было интересно, знал ли кто-нибудь о лучшем пути?

Ответы

Ответ 1

Вот как я это сделал (http://sajojacob.com/2009/08/how-to-chain-tfs-builds/)

Как объединить сборки TFS? Опубликовано 5 августа 2009 по Sajo - Нет комментариев ↓

Один из моих коллег @gdurzi недавно задал мне этот вопрос. Звучит достаточно просто, чтобы получить поддержку из коробки с TFS? С этим слишком много причуд. И я рекомендовал использовать всегда верную задачу MSBuild для вызова TFSBuild.exe для очереди новой сборки из первого TFSBuild.proj с чем-то вроде этого

TFSBuild.exe start/queue% TFSSVR%% TEAMPROJECT%% BUILDTYPE%

Проблема с использованием TFSBuild.exe заключается в том, что вы не можете передавать агенты Build в качестве аргумента командной строки, который был для нас нарушением.

Существует несколько подходов, которые вы можете использовать на основе вашего конкретного сценария, поэтому давайте определим сценарий здесь, у вас есть определение сборки Main_Build TFS, которое строит ваш основной проект, и вы хотите, чтобы несколько промежуточных построек запускали тот же Main_Build для компиляции/построения, но настраиваться для развертывания на основе того, кто называет Main_Build. Очень полезно, когда у вас есть продукт, который выворачивается нескольким клиентам с необходимостью пользовательских операций предварительной сборки и последующей сборки на каждого клиента. Итак, вот один из способов сделать сборку цепочек с TFS 2008.

Шаг 1. Создаем настраиваемую задачу MSBuild с использованием объектной модели Team Foundation, которая ставит очередь сборки, используя агент сборки по умолчанию, связанный с файлом определения сборки.

Пример кода для очереди: QueueTFS.cs

using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Build.Client;

// Get the team foundation server. 
TeamFoundationServer _tfsServer = TeamFoundationServerFactory.GetServer(_tfs); 

// Get the IBuildServer 
IBuildServer buildServer = (IBuildServer)_tfsServer.GetService(typeof(IBuildServer)); 

// Get the build definition for which a build is to be queued. 
IBuildDefinition definition = buildServer.GetBuildDefinition(teamProject, buildDefinition); 

// Create a build request for the build definition. 
IBuildRequest request = definition.CreateBuildRequest(); 
request.CommandLineArguments = "Pass any custom command line args here"; // Ex: Custom Targets file

// Queue the build. 
buildServer.QueueBuild(request, QueueOptions.None);

Шаг 2: Теперь скопируйте QueueTFS.dll в новую папку в TFS, где вы хотите создать файл определения сборки.

Теперь создадим минимальный файл TFSBuild.proj, который использует нашу новую задачу MSBuild и переопределяет цель EndToEndIteration. Это будет наше определение Staging build, которое вызовет сборку Main_Build. Обратите внимание, что вам нужно будет создать этот TFSBuild.proj вручную и просто указать местоположение файла проекта из пользовательского интерфейса определения сборки в новую папку.

Пример кода для минимального TFSBuild.proj:

<?xml version="1.0" encoding="utf-8"?> 
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5"> 
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" /> 
  <UsingTask TaskName="MyNewCustomTFSTask" AssemblyFile="QueueTFS.dll"/> 
  <Target Name="EndToEndIteration"> 
    <Message Text="About to trigger main build" Importance="high"/> 
    < MyNewCustomTFSTask TFS="http://TFSServer.com:8080/" TeamProject="TeamProject" BuildDefinition="Main_Build" TargetsFile="Custom.Target" XYZ="XYZ" /> 
    <!-- When everything is done, change the status of the task to "Succeeded" --> 
    <SetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" TestStatus="Succeeded" CompilationStatus="Succeeded"/> 
  </Target> 
</Project>

Шаг 3: отредактируйте файл Main_Build TFSBuild.proj с помощью целевых вызовов предварительной сборки и последующей сборки.

  <Target Name="BeforeCompile">

    <CallTarget Targets="Custom_PreBuild"/>    

  </Target>

  <Target Name="AfterDropBuild" Condition="‘$(BuildBreak)’!=’true’">    

    <CallTarget Targets="Custom_PostBuild"/>

  </Target>

Мы хотели иметь возможность запускать Main_Build сами по себе, чтобы поддержать это, добавив условный импорт в наш Main_Build TFSBuild.proj, чтобы импортировать файл целей по умолчанию с пустыми объектами Custom_PreBuild и Custom_PostBuild. $(CustomTarget) - это то, что вы передали бы в качестве аргумента командной строки на шаге 1 для request.CommandLineArguments

<Import Project="$(CustomTarget)" Condition="'$(CustomTarget)'!=''"/>
<!--Import CustomContoso.Target if no partner is passed in—>
<Import Project="EmptyCustom.Target" Condition="'$(CustomTarget)'==''"/> 

Шаг 4: Теперь создайте свой файл целей Custom.Target и EmptyCustom.Target с настройками Custom_PreBuild и Custom_PostBuild, и все готово.

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

Ответ 2

Это зависит от того, что вы пытаетесь сделать.

1) Вы хотите, чтобы сценарий сборки + выполнялся как одна операция? Итак, вы получаете один консолидированный отчет о сбое, один файл журнала, одно задание в очереди сборки сервера, каждый шаг, выполняемый последовательно одним и тем же агентом сборки, который выполнил предыдущий шаг?

Если это так, значит, вы находитесь на правильном пути. Я бы не <Exec > out to tfsbuild.exe, хотя - запуск всей новой сборки имеет много накладных расходов, и я не уверен, каковы потенциальные побочные эффекты. Вместо этого я бы использовал задачу <Call > для выполнения задач msbuild, определенных в вашем промежуточном script (s).

2) Вы хотите, чтобы "сборка сборки" фактически оставила отдельную "промежуточную сборку"? Отдельные отчеты, файлы журналов и места в очереди? Возможность запускаться параллельно, если у вас несколько агентов сборки?

Если да, то:

  • создать новое определение для сборки
  • добавьте некоторый код в свое исходное определение сборки, которое ставит в очередь [один/несколько] новых определений сборки с помощью Team Build API. Пример кода.
  • удалить все, что не связано с построением ядра из исходного определения сборки
  • убедитесь, что в новых определениях "постановки" нет автоматических триггеров (интервалы времени, события проверки и т.д.).

Ответ 3

Вот еще полезные ссылки. Это может помочь другим.

Создайте другое определение сборки и вызовите другие определения построения, которые будут запущены.

http://blogs.objectsharp.com/post/2012/02/04/Create-a-Master-Build-that-calls-other-Builds.aspx

http://blog.stangroome.com/2011/09/06/queue-another-team-build-when-one-team-build-succeeds/

Передача аргументов в дочерние сборки.

http://blog.stangroome.com/2014/02/19/queue-a-team-build-from-another-and-pass-parameters/

Расширение сборки TFS в очереди на другое определение сборки

http://tfsbuildextensions.codeplex.com/

Ответ 4

Вы пытаетесь развернуть свое решение в своей промежуточной среде? Если это хороший способ использовать TFSDeployer из codeplex, который будет запускать другой PowerShell script на основе выбранного вами качества сборки...