Este artigo foi traduzido por máquina.

O Team System

Equipe de compilação 2008 personalização

Brian A. Randell

Conteúdo

Propriedades
Ao obter informações sobre o que é going em
As alterações
Tarefas personalizadas

Na minha coluna novembro de 2008Equipe Foundation Build 2008, Discuti o que é Team Build 2008, por que você se preocupar com, como criar uma compilação e como usar a nova API para programar o serviço Team Build.Nesta coluna, vou abordar como você pode modificar o comportamento padrão do Team Build, estender as compilações com tarefas personalizadas e fazer uso dos aprimoramentos adicionados como parte do Team Build 2008 SP1.

Antes de começar a personalizar sua compilação, no entanto, é importante lembrar que a Microsoft construiu Team Build na parte superior do Microsoft Build Engine (MSBuild), um componente principal do Microsoft .NET Framework 2.0.Enquanto que será fornecem alguns pontos atualizador secundária relacionados como MSBuild executa uma compilação, você deve ter uma compreensão decente a acompanharem.Para uma revisão de BOM, você pode ler a junho de 2006 MSDN artigo no MSBuild "Compilar seu modo com tarefas de personalizar aplicativos para O mecanismo Microsoft Build."

Como já mencionei antes, eu recomendo que você explore personalização do Team System e nesse caso Team Build, em um ambiente nonproduction primeiro.Uma boa maneira de, obviamente, é usar uma das máquinas virtuais avaliação Microsoft-fornecido.Eu atualizado as imagens antes de 2008 de Natal, portanto, você encontrará as novas disponíveis com o SP1 instalado, bem como outras atualizações.As imagens estão disponíveis para Virtual PC e Hyper-V.Você encontrará links e obter mais detalhes naBlog do Pluralsight.

Um número de partes móveis está envolvido na execução de uma compilação.a Figura 1 (a partir o artigo do MSDN"Visão geral de compilação Foundation de equipe") fornece uma exibição ilustrada de todas as partes.Além disso, descrevi as etapas gerais do que ocorre na minha coluna anterior.O que estamos mais preocupados com aqui é quando o MSBuild é envolvido.O serviço Team Build (TFSBuildService.exe) cria um processo do MSBuild, passando o local de um arquivo chamado TFSBuild.tbrsp.Você encontrará o arquivo na subpasta BuildType no diretório de trabalho do agente sua criação.

fig01.gif

Figura 1 Visão geral dos componentes de criação

O serviço de Team Build 2008 SP1 gera TFSBuild.tbrsp dinamicamente.O arquivo consiste em dados armazenados em bancos de dados do Team Build, Team Build controlada parâmetros e o conteúdo (se houver) do arquivo de TFSBuild.rsp sua compilação.a Figura 2 é um exemplo de uma compilação de teste que criei.

A Figura 2 Example de uma compilação de teste

### Begin Team Build Generated Arguments ###

/nodeReuse:false
/m:1
/nologo
/noconsolelogger
/dl:BuildLogger,"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\
  PrivateAssemblies\Microsoft.TeamFoundation.Build.Server.Logger.dll";
"BuildUri=vstfs:///Build/Build/45;
TFSUrl=http://tfsrtm08:8080/;
TFSProjectFile=C:\Builds\ExploreTeamBuild\Sysinfo\BuildType\TFSBuild.proj;ServerUICulture=1033;
LogFilePerProject=False;
"*BuildForwardingLogger,"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\
  PrivateAssemblies\Microsoft.TeamFoundation.Build.Server.Logger.dll";
"BuildUri=vstfs:///Build/Build/45;TFSUrl=http://tfsrtm08:8080/;
TFSProjectFile=C:\Builds\ExploreTeamBuild\Sysinfo\BuildType\TFSBuild.proj;ServerUICulture=1033;"
/fl /flp:logfile=BuildLog.txt;encoding=Unicode;
/p:BuildDefinition="Sysinfo" 
/p:BuildDefinitionId="3" 
/p:DropLocation="\\localhost\Drops" 
/p:BuildProjectFolderPath="$/ExploreTeamBuild/TeamBuildTypes/Sysinfo" 
/p:BuildUri="vstfs:///Build/Build/45" 
/p:TeamFoundationServerUrl="http://tfsrtm08:8080/" 
/p:TeamProject="ExploreTeamBuild" 
/p:SourcesSubdirectory="Sources" 
/p:BinariesSubdirectory="Binaries" 
/p:TestResultsSubdirectory="TestResults" 
/p:SourceGetVersion="C244" 
/p:LastGoodBuildLabel="Sysinfo_20090104.2@$/ExploreTeamBuild" 
/p:LastBuildNumber="Sysinfo_20090104.2" 
/p:LastGoodBuildNumber="Sysinfo_20090104.2" 
/p:NoCICheckInComment="***NO_CI***" 
/p:IsDesktopBuild="false" 
/p:TeamBuildRefPath="C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies" 
/t:EndToEndIteration

TFSBuild.proj

### End Team Build Generated Arguments ###

### Begin Checked In TfsBuild.rsp Arguments ###

# This is a response file for MSBuild
# Add custom MSBuild command line options in this file

### End Checked In TfsBuild.rsp Arguments ###

Se você criar uma compilação em Team Build 2005, ele armazena muita os dados de compilação em um conjunto de arquivos sob controle de versão em um local fixo. O mais interessante desses arquivos é TFSBuild.proj, um arquivo XML que estejam de acordo com o esquema de arquivo de projeto MSBuild. Quando você cria uma compilação usando o Team Foundation Server 2008, Team Build 2008 armazena a maioria das informações que você fornecer dentro de bancos de dados do TFS. No entanto, você personalizar o processo de compilação a mesma maneira independentemente da versão: você editar o arquivo TFSBuild.proj e gravar tarefas MSBuild personalizadas (se necessário).

No Team Build 2008 SP1, você pode acessar o arquivo TFSBuild.proj clicando com o botão direito do mouse no nome de uma definição de compilação na janela Team Explorer e selecionando Exibir configuração de compilação. Nas versões anteriores ao SP1, você abrir o Gerenciador de controle de origem e navegar manualmente para o local especificado ao executar o Assistente de definição de compilação.

A definição de compilação armazenada no banco de dados define o que deve ser criado e quando. O arquivo TFSBuild.proj define como o Team Build deve executar a compilação. Você irá recuperar da minha coluna anterior que você pode criar um novo arquivo TFSBuild.proj você criar uma nova definição de compilação, ou você pode apontar para um arquivo existente já sob controle de versão. Para MSBuild fazer sua mágica, em conjunto com vários assemblies de Team Build, ele precisa saber o que criar e em que ordem, bem como sobre as tarefas adicionais. Se você examinar a Figura 2 , você observará que Team Build passa TFSBuild.proj como o nome do arquivo de projeto MSBuild deve processar. O MSBuild trata todos os argumentos /p como propriedades globais.

Se você examinar um arquivo de Team Build 2008 TFSBuild.proj para uma compilação que cria uma única solução (ambos depuração e versão tipos de configuração) e não executar quaisquer testes, você encontrará um número de seções. Este arquivo XML é muito semelhante a um arquivo de projeto Visual Basic ou C#. O arquivo XML define propriedades de compilação, artefatos para incluir como parte do processo de criação e operações para executar. O arquivo agrupa elementos juntos em <propertygroup> de propriedades. Ele controla artefatos como soluções em <itemgroup> elementos. Além disso, ele descreve operações que ele deve ser executado em conjunto via <target> elementos.

Destinos tem um atributo Name e eles agrupar tarefas juntos em uma ordem específica. Você definir as tarefas no CLR-dependente assemblies Criando classes públicas que implementam ITask ou herdam a base abstrata de classe tarefas (ou qualquer outros derivados tipos, como ToolTask). ITask, tarefas e ToolTask ao vivo no assembly Microsoft.Build.Utilities.dll. No arquivo TFSBuild.proj, após a declaração XML, você encontrará a raiz <project> elemento necessário para MSBuild:

<Project DefaultTargets="DesktopBuild" 
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

O atributo DefaultTargets Especifica que o MSBuild deve usar o destino DesktopBuild. No entanto, isso ocorre apenas se você executar a compilação usando MSBuild diretamente. Se você retornar à Figura 2 , você verá que Team Build informa MSBuild a considerar o destino EndToEndIteration como seu ponto de entrada principal. Portanto, MSBuild ignora o atributo DefaultTargets quando iniciado pelo Team Build.

Após o elemento <project><import>, você encontrará um elemento <importação>. <import>O elemento <importação> informa MSBuild para usar outro arquivo de projeto em adição à processadas. <import>Criar da equipe aponta o elemento <importação> para o arquivo de destinos Team Build do específico da versão:

<!-- Do not edit this -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

Este arquivo de público-alvo é o coração e a alma do como Team Build faz sua mágica. Um exame cuidadoso desse arquivo fornecerá profundidade esclarecimento sobre o processo de Team Build bem como funciona o MSBuild. Uma palavra de aviso: você não deve editar esse arquivo de público-alvo. Isso afeta todas as compilações em um agente de compilação específico (mas somente agente). Além disso, se a Microsoft fornece um service pack, hotfix ou atualização para o Team Build, suas alterações poderia ser perdidas. Finalmente, não é uma operação de suporte Microsoft. Você deve usar os mecanismos internos para ajustar comportamento do Team Build em vez disso, algo que você vai saber nesta coluna.

Como parte da sua pré-processamento, MSBuild cria uma árvore de destinos a serem executados. A ordem em que um arquivo de projeto define alvos é irrelevante. O MSBuild executa destinos com base no destino do ponto de entrada e os atributos de DependsOn supondo que nenhum erro ocorrer. Além disso, o MSBuild somente executará uma versão nomeada de um destino. Ele usa a última versão de um destino definido. Criar da equipe aproveita isso definindo um número de destinos vazios no arquivo de destinos Team Build. A maioria desses destinos tem um prefixo de antes ou após em seus nomes. <import>O MSBuild processa os destinos definidos no arquivo destinos Team Build primeiro por causa do elemento <importação>.

Você, por sua vez, pode substituir um desses destinos ao criar um destino com o mesmo nome no arquivo TFSBuild.proj. No entanto, alguns itens adicionais também afeta a ordenação de destino. Primeiro, a raiz elemento <project> oferece suporte a um elemento InitialTargets, que pode conter uma lista delimitada por ponto-e-vírgula de um ou mais destinos para executar antes do DefaultTargets ou aquelas especificadas na linha de comando. Em segundo lugar, um alvo pode especificar que ele depende um ou mais destinos usando o atributo DependsOnTargets. O MSBuild executa os alvos listados em um atributo DependsOnTargets na ordem em que elas são declaradas. Muitas dos destinos Team Build fazer exatamente isso. Em terceiro lugar, um destino pode especificar uma condição para a sua execução. Por exemplo, muitos dos destinos Team Build executar somente se a compilação não for uma compilação da área de trabalho. Portanto, quando você executa um Team Build, o conjunto inicial de destinos que executa é CanonicalizePaths primeiro e, em seguida, CheckSettingsForEndToEndIteration.

O MSBuild executa CanonicalizePaths primeiro porque o arquivo de destinos define-lo como o item InitialTargets. CheckSettingsForEndToEnd­Iteration é próxima porque é o primeiro destino a lista de Depends­OnTargets especificado para EndToEndIteration, o destino especificado pelo Team Build na linha de comando do MSBuild. Observe que o MSBuild somente executa alvo que esteja na cadeia de EndToEndIteration.

Neste ponto, você saberá o suficiente para começar. Primeira parte desta coluna, criei um Team Project, MSDNMag, com um espaço de trabalho personalizado. Irá continuar a usar esse projeto de equipe para os exemplos aqui. Verifiquei em todas as minhas soluções de exemplo em $ msdnmag/principal/src/TeamSystem/C10 /. Meu espaço de trabalho personalizado chamado MSDNMag mapeia o tronco de MSDNMag de $ meu projeto de equipe para C:\Work\MSDNMag para facilitar trabalhar com as soluções, bem como os arquivos de compilação. Por fim, como mencionei anteriormente, ESTOU fazendo tudo isso na versão Team System 2008 SP1 da máquina virtual Microsoft-fornecido.

Ao Iniciar trabalho pela primeira vez no Team Build personalizações, você precisará Observe duas coisas. Um, você poderá estar editando arquivos XML para criar suas personalizações. Em segundo lugar, depuração hoje tende a ser tudo sobre printf e analisando arquivos de log. When você considerar personalizando sua compilação para ajustar seu comportamento, há três maneiras gerais de continuar. Primeiro, altere o valor das propriedades conhecidas. Em segundo lugar, chamar tarefas predefinidas. Em terceiro lugar, escreva sua própria tarefa personalizada.

O MSBuild e Team Build expõem um número de propriedades que você pode usar para definir condições que afetam a execução de destino. Por exemplo, Team Build expõe uma propriedade IsDesktopBuild que ele usa para determinar se devem executar determinados destinos. O MSBuild expõe propriedades relacionadas para a plataforma, opções do compilador, arquitetura de processador e mais. Além disso, Team Build tem um número de propriedades que você pode alterar para ativar ou desativar recursos. Na verdade, análise de código é um dos itens que você pode ajustar.

Se você examinar o arquivo TFSBuild.proj, você encontrará um pouco de XML com o código a seguir. Alterando o valor da propriedade <runcodeanalysis>, você alterar como o MSBuild evalutes código configurações de análise em seus projetos:

<!--  CODE ANALYSIS
Set this property to enable/disable running code analysis. Valid values for this property are Default, Always and Never.

     Default—Perform code analysis as per the individual project settings
     Always —Always perform code analysis irrespective of project settings
     Never —Never perform code analysis irrespective of project settings
 -->
<RunCodeAnalysis>Never</RunCodeAnalysis>

Criar da equipe também usa propriedades para controlar a execução de testes. Isso envolve vários fragmentos XML. Primeiro, defina a propriedade <Run­Test> como true. Em seguida, você usar listas de teste ou ter Team Build procurar testes a serem executados. Se você quiser usar listas de teste, você precisará definir uma propriedade <metadatafile> com um ou mais itens <testlist>, como você pode ver aqui:

<!--Set this flag to enable/disable running tests as a post-compilation build step.-->
<RunTest>true</RunTest>
<MetaDataFile Include=
  "$(BuildProjectFolderPath)/../../Main/src/SysInfo/SysInfo.vsmdi">
  <TestList>All Unit Tests</TestList>
</MetaDataFile>

Aqui está um exemplo de mais de propriedades em ação. Durante a execução normal build, Team Build rótulos de todos os artefatos recuperado do controle de versão. Se você quiser que isso aconteça, você somente precisará definir a propriedade SkipLabel como true. Você pode fazer isso de diversas maneiras. Primeiro, se só desejar fazer isso por uma seqüência específica de sua compilação, você pode passar /p:SkipLabel = true nos argumentos de linha de comando do MSBuild (veja a Figura 3 ). Observe, entretanto, que se você apenas passar SkipLabel, você obterá um erro de compilação quando Team Build tenta gerar a lista de changesets e atualizar itens de trabalho. Para evitar o erro, você deseja adicionar SkipGetChangesetsAndUpdateWork­Items = true. Você encontrará seus argumentos de linha de comando visível na seção resumo do relatório compilação.

fig03.gif

A Figura 3 passar argumentos de linha de comando para MSBuild

Além da linha de comando, você pode usar a mesma sintaxe, mas em vez de usar a caixa de diálogo, edite o arquivo de TFSBuild.rsp que você encontrará lado-lado com seu arquivo TFSBuild.proj no controle de versão. Por fim, você pode adicionar as propriedades para o seu arquivo TFSBuild.proj. Você precisará extrair o arquivo TFSBuild.proj do controle de versão. Se você clicar duas vezes no arquivo, ele será aberto no editor do Visual Studio.

Você pode adicionar cada propriedade usando o XML de abertura e fechamento marcas de elemento com true para texto do elemento a um grupo de propriedade existente, ou você pode criar seu próprio grupo de propriedade — até mesmo vai até o momento como adicionar um parâmetro de condição para que você pode ativá-la e desativar através da linha de comando conforme mostrado aqui. Agora você pode passar /p:QuickBuild = True para fazer uma compilação rápida:

<PropertyGroup Condition="$(QuickBuild)=='True'">
    <SkipLabel>true</SkipLabel>
    <SkipGetChangesetsAndUpdateWorkItems>true</SkipGetChangesetsAndUpdateWorkItems>
</PropertyGroup>

Ao obter informações sobre o que é going em

Quando você inicia a futz com sua compilação e descobrir o que realmente está acontecendo, você geralmente precisará saída informações de status adicionais. Antes disso, lembre-se de que por padrão Team Build gera um log detalhado. Você pode ajustar a verbosidade desse log usando o fileLoggerParameters (flp) argumento (Team Build 2005 usado o argumento / v). No Microsoft .NET Framework 3.5, o log padrão é alterado de detalhamento normal para diagnóstico. Assim, se desejar menores arquivos de log, você será deseja adicionar /flp:verbosity = normal para o seu arquivo TFSBuild.rsp.

Se você não encontrar o que você está procurando no log detalhado, você pode iniciar gravar suas próprias mensagens no arquivo de log. Para efetuar uma mensagem, você precisará definir um destino. No destino, você pode usar a tarefa de mensagem interna. </project>Por exemplo, para gravar fora a seqüência "Meu Custom Message" como bem como o valor da propriedade SkipLabel, adicione o seguinte XML ao arquivo TFSBuild.proj apenas antes o elemento de fechamento:

<Target Name="MyMessageLogger">
        <Message Text="My Custom Message" />
        <Message Text="SkipLabel Status= $(SkipLabel)" />
</Target>

No entanto, se você fizer isso e executar sua compilação, nada acontece. Lembre-se de que Team Build chama EndToEndIteration como seu ponto de entrada. O MSBuild somente executa destinos na cadeia da execução do destino. Se você quiser executar a tarefa, você precisará conectar seu público-alvo para esta cadeia. Uma maneira simples seria adicionar o destino ao arquivo de destinos Team Build. No entanto, você não fazer isso porque, lembre-se, você já foi avisado "não fazer isso!" Acontece que duas alternativas muito razoáveis que a Microsoft oferece suporte e até mesmo encoraja. O outro é modificar a propriedade de DependsOn um destino para inserir um destino personalizado a cadeia de dependência.

Como mencionado anteriormente, o arquivo de destinos Team Build define um número de destinos vazios. A Microsoft criou esses destinos expressamente para que você pode substitui-los. Você encontrará uma lista no artigo MSDN" Personalizáveis Team Foundation Build destinos."

O processo de compilação de equipe tem mais de 20 pontos onde você pode facilmente obter Team Build para executar suas operações personalizadas. O primeiro destino que você pode substituir é BeforeEndToEndIteration. Isso efetivamente é o quarto destino que executa o MSBuild. Para obter o fragmento XML anterior para executar, você precisará alterar o atributo Name de MyMessageLogger para BeforeEndToEndIteration. Vai um passo adiante, se você quiser que sua mensagem aparecer no relatório de Team Build, você pode usar a tarefa de Team Build-desde BuildStep em vez da tarefa de mensagem, como mostrado aqui:

<Target Name="BeforeEndToEndIteration">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
           BuildUri="$(BuildUri)"
           Name="MyBuildStep"
           Message="BeforeEndToEndIteration override is executing."
           Status="Succeeded"
           >
    </BuildStep>
</Target>

Não todas as alterações feitas em Team Build pela Microsoft quando atualizar de 2005 para 2008 foram recebidas com músicas de praise. Para um, frowned nessa alteração: por padrão, Team Build 2008 marca uma compilação bem-sucedida se ele não encontrar um erro durante o processo de compilação. Isso ignora a noção de uma compilação parcialmente bem-sucedida. Equipe de conjuntos de compilação que status de uma compilação para este estado se a compilação tiver êxito, mas algo mais, tais como um teste de unidade, falhará. Por outro lado, Team Build 2005 falha uma compilação se um teste falhar.

Não é necessário dizer que essa alteração não está que todos queria. Para contornar esse comportamento no Team Build 2008 sem o SP1, você pode usar uma técnica postada por Aaron Hallberg da Microsoft falhe compilações quando um ou mais testes falhar. Figura 4 lista o XML que você precisa adicionar ao seu arquivo TFSBuild.proj. Este destino primeiro obtém a propriedade TestSuccess. Em seguida, ele altera a propriedade CompilationStatus para Failed se TestSuccess for igual a false. Felizmente, a Microsoft ouviu aos comentários. Uma propriedade foi adicionada no Team Build 2008 SP1 que resolvem esse problema. Simplesmente defina <treattestfailureasbuildfailure> como true, e você está pronto.

A Figura 4 XML que deve ser adicionada ao arquivo TFSBuild.proj

<Target Name="AfterTest">

  <!-- Refresh the build properties. -->
  <GetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                      BuildUri="$(BuildUri)"
                      Condition=" '$(IsDesktopBuild)' != 'true' ">
    <Output TaskParameter="TestSuccess" PropertyName="TestSuccess" />
  </GetBuildProperties>

  <!-- Set CompilationStatus to Failed if TestSuccess is false. -->
  <SetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                      BuildUri="$(BuildUri)"
                      CompilationStatus="Failed"
                      Condition=" '$(IsDesktopBuild)' != 'true' and '$(TestSuccess)' != 'true' ">

</Target>

Tarefas personalizadas

Até agora, você alterou a forma MSBuild e Team Build operam, alterando o XML no TFSBuild.proj. Mas e se você quiser implantar um projeto de Web para o IIS após uma compilação conclusão? Se você deseja empacotar up seus binários em um arquivo MSI? Uma solução é criar uma tarefa personalizada, mas há um amor das bibliotecas de tarefas do MSBuild e Team Build já disponíveis na Internet para seu uso e a maioria deles fornece o código-fonte completo.

Duas bibliotecas principais que você deve começar com são no CodePlex. Há o Tarefas SDCcom mais de 300 tarefas. Além disso, há o Pacote de extensão do MSBuildcom as tarefas em mais de 250. Cada biblioteca possui uma grande variedade de tarefas e fornecem fonte. Usando essas bibliotecas requer que você instalar os assemblies em suas máquinas de agente de compilação e, em seguida, adicione o fragmento XML apropriado ao arquivo TFSBuild.proj.

A Microsoft criou o Team Build 2008 seja extremamente flexível. Obter o máximo dele começa com Noções básicas sobre como ele funciona e interage com o MSBuild. Com esse conhecimento e um pouco de edição de XML, você pode alterar facilmente seu comportamento. Com a ajuda da comunidade, você pode ir muito mais e adicionar completamente novos recursos ao Team Build. Finalmente, se você não conseguir localizar a tarefa para fazer exatamente o que deseja, você pode criar seus próprios tarefas personalizado.

Envie suas dúvidas e comentários para Brian para mmvsts@Microsoft.com.

Brian a. Randell é um consultor sênior da MCW Technologies, LLC. Ele passa seu tempo falando, ensinando e escrevendo sobre tecnologias da Microsoft. Brian é autor do curso Applied Team System da Pluralsight e é um MVP da Microsoft. Entre em contato com Brian pelo seu blog em mcwtech.com/cs/blogs/brianr.