Criação de uma definição de build compatível com a implantação

por Jason Lee

Se você quiser executar qualquer tipo de build no Team Foundation Server (TFS) 2010, será necessário criar uma definição de build dentro do projeto de equipe. Este tópico descreve como criar uma nova definição de build no TFS e como controlar a implantação da Web como parte do processo de build no Team Build.

Este tópico faz parte de uma série de tutoriais baseados nos requisitos de implantação empresarial de uma empresa fictícia chamada Fabrikam, Inc. Esta série de tutoriais usa uma solução de exemplo, a solução do Contact Manager, para representar um aplicativo Web com um nível realista de complexidade, incluindo um aplicativo ASP.NET MVC 3, um serviço WCF (Windows Communication Foundation) e um projeto de banco de dados.

O método de implantação no centro desses tutoriais baseia-se na abordagem de arquivo de projeto dividido descrita em Noções básicas sobre o arquivo de projeto, na qual o processo de build e implantação é controlado por dois arquivos de projeto— um contendo instruções de build que se aplicam a cada ambiente de destino e outro que contém configurações de build e implantação específicas do ambiente. No momento da compilação, o arquivo de projeto específico do ambiente é mesclado no arquivo de projeto independente do ambiente para formar um conjunto completo de instruções de build.

Visão geral da tarefa

Uma definição de build é o mecanismo que controla como e quando os builds ocorrem para projetos de equipe no TFS. Cada definição de build especifica:

• As coisas que você deseja criar, como arquivos de solução do Visual Studio ou arquivos de projeto de Microsoft Build Engine personalizados (MSBuild).
• Os critérios que determinam quando um build deve ocorrer, como gatilhos manuais, CI (integração contínua) ou marcar-ins fechados.
• O local para o qual o Team Build deve enviar saídas de build, incluindo artefatos de implantação, como pacotes Web e scripts de banco de dados.
• A quantidade de tempo que cada compilação deve ser mantida.
• Vários outros parâmetros do processo de build.

Observação

Para obter mais informações sobre definições de build, consulte Definir seu processo de build.

Este tópico mostrará como criar uma definição de build que usa CI, para que um build seja disparado quando um desenvolvedor fizer check-in de um novo conteúdo. Se o build for bem-sucedido, o serviço de build executará um arquivo de projeto personalizado para implantar a solução em um ambiente de teste.

Quando você dispara um build, essas ações precisam acontecer:

• Primeiro, o Team Build deve criar a solução. Como parte desse processo, o Team Build invocará o WPP (Web Publishing Pipeline) para gerar pacotes de implantação da Web para cada um dos projetos de aplicativo Web na solução. O Team Build também executará todos os testes de unidade associados à solução.
• Se o build da solução falhar, o Team Build não deverá executar nenhuma ação adicional. As falhas de teste de unidade devem ser tratadas como uma falha de build.
• Se o build da solução for bem-sucedido, o Team Build deverá executar o arquivo de projeto personalizado que controla a implantação da solução. Como parte desse processo, o Team Build invocará a Ferramenta de Implantação da Web (Implantação da Web) dos Serviços de Informações da Internet (IIS) para instalar os aplicativos Web empacotados nos servidores Web de destino e invocará o utilitário VSDBCMD.exe para executar scripts de criação de banco de dados nos servidores de banco de dados de destino.

Isso ilustra o processo:

A solução de exemplo do Gerenciador de Contatos inclui um arquivo de projeto personalizado do MSBuild, Publish.proj, que você pode executar no MSBuild ou no Team Build. Conforme descrito em Noções básicas sobre o processo de build, esse arquivo de projeto define a lógica que implanta seus pacotes Web e bancos de dados em um ambiente de destino. O arquivo inclui a lógica que omite o processo de compilação e empacotamento se ele estiver em execução no Team Build, deixando apenas as tarefas de implantação a serem executadas. Isso ocorre porque, ao automatizar a implantação dessa maneira, você normalmente desejará garantir que a solução seja compilada com êxito e passe em todos os testes de unidade antes do início do processo de implantação.

A próxima seção explica como implementar esse processo criando uma nova definição de build.

Observação

Esse procedimento, no qual um único processo automatizado cria, testa e implanta uma solução, provavelmente será mais adequado para implantação em ambientes de teste. Para ambientes de preparo e produção, é muito mais provável que você queira implantar conteúdo de um build anterior que você já verificou e validou em um ambiente de teste. Essa abordagem é descrita no próximo tópico, Implantando um build específico.

Quem executa este procedimento?

Normalmente, um administrador do TFS executa esse procedimento. Em alguns casos, um líder de equipe de desenvolvedores pode assumir a responsabilidade pela coleção de projetos de equipe no TFS. Para criar uma nova definição de build, você precisa ser membro do grupo Administradores de Build da Coleção de Projetos para a coleção de projetos de equipe que contém sua solução.

Criar uma definição de build para CI e implantação

O próximo procedimento descreve como criar uma definição de build que a CI dispara. Se o build for bem-sucedido, a solução será implantada usando a lógica em um arquivo de projeto personalizado do MSBuild.

Para criar uma definição de build para CI e implantação

1. No Visual Studio 2010, na janela team Explorer, expanda o nó do projeto de equipe, clique com o botão direito do mouse em Builds e clique em Nova Definição de Build.

   

2. Na guia Geral , dê um nome à definição de build (por exemplo, DeployToTest) e uma descrição opcional.

3. Na guia Gatilho , selecione os critérios nos quais você deseja disparar um novo build. Por exemplo, se você quiser criar a solução e implantar no ambiente de teste sempre que um desenvolvedor fizer check-in no novo código, selecione Integração Contínua.

4. Na guia Padrões de Build, na caixa Copiar saída de build para a pasta suspensa a seguir , digite o caminho UNC (Convenção Universal de Nomenclatura) da pasta suspensa (por exemplo, \TFSBUILD\Drops).

   

   Observação

   Esse local de remoção armazena vários builds, dependendo da política de retenção configurada. Quando você deseja publicar artefatos de implantação de um build específico para um ambiente de preparo ou produção, é aqui que você os encontrará.

5. Na guia Processo , na lista suspensa Arquivo do processo de build, deixe DefaultTemplate.xaml selecionado. Esse é um dos modelos de processo de build padrão que são adicionados a todos os novos projetos de equipe.

6. Na tabela Parâmetros do processo de build, clique na linha Itens para Compilar e, em seguida, clique no botão de reticências .

   

7. Na caixa de diálogo Itens para Compilar , clique em Adicionar.

8. Navegue até o local do arquivo de solução e clique em OK.

   

9. Na caixa de diálogo Itens para Compilar , clique em Adicionar.

10. Na lista suspensa Itens do tipo , selecione Arquivos do Projeto do MSBuild.

11. Navegue até o local do arquivo de projeto personalizado com o qual você controla o processo de implantação, selecione o arquivo e clique em OK.

    

12. A caixa de diálogo Itens para Compilar agora deve mostrar dois itens. Clique em OK.

    

13. Na guia Processo , na tabela Parâmetros do processo de build, expanda a seção Avançado .

14. Na linha Argumentos do MSBuild , adicione os argumentos de linha de comando do MSBuild que qualquer um dos seus itens para compilar requer. No cenário de solução do Gerenciador de Contatos, esses argumentos são necessários:

    /p:DeployOnBuild=true;DeployTarget=Package;
       TargetEnvPropsFile=EnvConfig\Env-Dev.proj
    

    

15. Neste exemplo:

    1. Os argumentos DeployOnBuild=true e DeployTarget=package são necessários quando você cria a solução do Contact Manager. Isso instrui o MSBuild a criar pacotes de implantação da Web depois de criar cada projeto de aplicativo Web, conforme descrito em Compilando e empacotando projetos de aplicativo Web.
    2. O argumento TargetEnvPropsFile é necessário quando você compila o arquivo Publish.proj . Essa propriedade indica o local do arquivo de configuração específico do ambiente, conforme descrito em Noções básicas sobre o processo de build.

16. Na guia Política de Retenção , configure quantos builds de cada tipo você deseja reter conforme necessário.

17. Clique em Save (Salvar).

Enfileirar uma compilação

Neste ponto, você criou pelo menos uma nova definição de build. O processo de build que você definiu agora será executado de acordo com os gatilhos especificados na definição de build.

Se você tiver configurado sua definição de build para usar a CI, poderá testar sua definição de build de duas maneiras:

• Verifique algum conteúdo no projeto de equipe para disparar um build automático.
• Enfileirar um build manualmente.

Para enfileirar um build manualmente

1. Na janela Team Explorer, clique com o botão direito do mouse na definição de build e clique em Enfileirar Novo Build.

   

2. Na caixa de diálogo Compilação de Fila , examine as propriedades de build e clique em Fila.

   

Para examinar o progresso e o resultado de um build, independentemente de ele ter sido disparado manual ou automaticamente, clique duas vezes na definição de build na janela team Explorer. Isso abrirá uma guia Criar Explorer.

A partir daqui, você pode solucionar problemas de builds com falha. Se você clicar duas vezes em um build individual, poderá exibir informações resumidas e clicar em arquivos de log detalhados.

Você pode usar essas informações para solucionar problemas de builds com falha e resolver quaisquer problemas antes de tentar outro build.

Observação

Os builds que executam a lógica de implantação provavelmente falharão até que você tenha concedido ao servidor de build todas as permissões necessárias no ambiente de destino. Para obter mais informações, consulte Configurando permissões para implantação de build de equipe.

Monitorar o processo de build

O TFS fornece uma ampla gama de funcionalidades para ajudá-lo a monitorar o processo de build. Por exemplo, o TFS pode enviar um email ou exibir alertas na área de notificação da barra de tarefas quando um build for concluído. Para obter mais informações, consulte Executar e monitorar builds.

Conclusão

Este tópico descreveu como criar uma definição de build no TFS. A definição de build é configurada para CI, portanto, o processo de build é executado sempre que um desenvolvedor verifica o conteúdo no projeto de equipe. A definição de build executa um arquivo de projeto personalizado do MSBuild para implantar pacotes Web e scripts de banco de dados em um ambiente de servidor de destino.

Para que uma implantação automatizada tenha êxito como parte de um processo de build, você precisará conceder as permissões apropriadas para a conta de serviço de build nos servidores Web de destino e no servidor de banco de dados de destino. O tópico final deste tutorial, Configurando permissões para implantação de build de equipe, descreve como identificar e configurar as permissões necessárias para a implantação automatizada de um servidor de Team Build.

Leitura Adicional

Para obter mais informações sobre como criar definições de build, consulte Criar uma definição de build básica e definir seu processo de build. Para obter mais diretrizes sobre como enfileirar builds, consulte Enfileirar um build.

AnteriorAvançar