Implantação de um build específico

Artigo
07/13/2023

Este tópico descreve como implantar pacotes da Web e scripts de banco de dados de um build anterior específico para um novo destino, como um ambiente de preparo ou de produção.

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

Até agora, os tópicos neste conjunto de tutoriais se concentraram em como criar, empacotar e implantar aplicativos Web e bancos de dados como parte de um processo de etapa única ou automatizado. No entanto, em alguns cenários comuns, você desejará selecionar os recursos implantados em uma lista de builds em uma pasta suspensa. Em outras palavras, o build mais recente pode não ser o build que você deseja implantar.

Considere o cenário de CI (integração contínua) descrito no tópico anterior, Criando uma definição de build que dá suporte à implantação. Você criou uma definição de build no Team Foundation Server (TFS) 2010. Sempre que um desenvolvedor verifica o código no TFS, o Team Build criará seu código, criará pacotes Web e scripts de banco de dados como parte do processo de build, executará todos os testes de unidade e implantará seus recursos em um ambiente de teste. Dependendo da política de retenção configurada quando você criou a definição de build, o TFS manterá um determinado número de builds anteriores.

Dependendo da política de retenção configurada quando você criou a definição de build, o T F S manterá um determinado número de builds anteriores. =======

Agora, suponha que você tenha realizado testes de verificação e validação em um desses builds em seu ambiente de teste e esteja pronto para implantar seu aplicativo em um ambiente de preparo. Enquanto isso, os desenvolvedores podem ter verificado o novo código. Você não deseja recompilar a solução e implantar no ambiente de preparo e não deseja implantar o build mais recente no ambiente de preparo. Em vez disso, você deseja implantar o build específico que verificou e validou nos servidores de teste.

Para fazer isso, você precisa informar ao Microsoft Build Engine (MSBuild) onde encontrar os pacotes Web e scripts de banco de dados gerados por um build específico.

Substituindo a propriedade OutputRoot

Na solução de exemplo, o arquivo Publish.proj declara uma propriedade chamada OutputRoot. Como o nome sugere, essa é a pasta raiz que contém tudo o que o processo de build gera. No arquivo Publish.proj , você pode ver que a propriedade OutputRoot se refere ao local raiz de todos os recursos de implantação.

Observação

OutputRoot é um nome de propriedade comumente usado. Os arquivos de projeto do Visual C# e do Visual Basic também declaram essa propriedade para armazenar o local raiz de todas as saídas de build.

<PropertyGroup>
  <!--This is where the .deploymanifest file will be written to during a build-->    
  <_DbDeployManifestPath>
    $(OutputRoot)ContactManager.Database.deploymanifest
  </_DbDeployManifestPath>    
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Mvc Web project -->
  <_ContactManagerDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Mvc_Package\
  </_ContactManagerDest>
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Service Web project -->
   <_ContactManagerSvcDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Service_Package\
  </_ContactManagerSvcDest>
  
  <!-- ... -->
</PropertyGroup>

Se você quiser que o arquivo de projeto implante pacotes da Web e scripts de banco de dados de um local diferente, como as saídas de um build anterior do TFS, basta substituir a propriedade OutputRoot . Você deve definir o valor da propriedade para a pasta de build relevante no servidor de Team Build. Se você estivesse executando o MSBuild na linha de comando, poderia especificar um valor para OutputRoot como um argumento de linha de comando:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\

Na prática, no entanto, você também desejará ignorar o Destino de build– não há nenhum ponto em criar sua solução se você não planeja usar as saídas de build. Você pode fazer isso especificando os destinos que deseja executar na linha de comando:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
  /target:GatherPackagesForPublishing;PublishDBPackages;PublishWebPackages

No entanto, na maioria dos casos, você desejará criar sua lógica de implantação em uma definição de build do TFS. Isso permite que os usuários com a permissão De builds de fila disparem a implantação de qualquer instalação do Visual Studio com uma conexão com o servidor TFS.

Criando uma definição de build para implantar builds específicos

O próximo procedimento descreve como criar uma definição de build que permite aos usuários disparar implantações em um ambiente de preparo com um único comando.

Nesse caso, você não quer que a definição de build realmente compile nada. Basta executar a lógica de implantação no arquivo de projeto personalizado. O arquivo Publish.proj inclui lógica condicional que ignora o destino build se o arquivo estiver em execução no Team Build. Ele faz isso avaliando a propriedade interna BuildingInTeamBuild , que é definida automaticamente como true se você executar o arquivo de projeto no Team Build. Como resultado, você pode ignorar o processo de build e simplesmente executar o arquivo de projeto para implantar um build existente.

Para criar uma definição de build para disparar a implantação manualmente

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.
Na guia Geral , dê um nome à definição de build (por exemplo, DeployToStaging) e uma descrição opcional.
Na guia Gatilho , selecione Manual – Check-ins não disparam um novo build.
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).

$Na guia Padrões de Build, na caixa Copiar saída de build para a pasta suspensa a seguir, digite o caminho U N C (Convenção Universal de Nomenclatura) da pasta suspensa (por exemplo, \TFSBUILD\Drops).$
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.
Na tabela Parâmetros do processo de build, clique na linha Itens para Compilar e, em seguida, clique no botão de reticências .
Na caixa de diálogo Itens para Compilar , clique em Adicionar.
Na lista suspensa Itens do tipo , selecione Arquivos do Projeto do MSBuild.
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.
Na caixa de diálogo Itens para Compilar , clique em OK.
Na tabela Parâmetros do processo de build, expanda a seção Avançado .
Na linha Argumentos do MSBuild, especifique o local do arquivo de projeto específico do ambiente e adicione um espaço reservado para o local da pasta de build:
```
/p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
OutputRoot=PLACEHOLDER
```
Observação

Você precisará substituir o valor OutputRoot sempre que enfileirar um build. Isso é abordado no próximo procedimento.
Clique em Save (Salvar).

Ao disparar um build, você precisa atualizar a propriedade OutputRoot para apontar para o build que deseja implantar.

Para implantar um build específico de uma definição de build

Na janela Team Explorer, clique com o botão direito do mouse na definição de build e clique em Enfileirar Novo Build.
Na caixa de diálogo Compilação de Fila , na guia Parâmetros , expanda a seção Avançado .
Na linha Argumentos do MSBuild , substitua o valor da propriedade OutputRoot pelo local da pasta de build. Por exemplo:
```
/p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
   OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
```
Observação

Certifique-se de incluir uma barra à direita no final do caminho para sua pasta de build.
Clique em Fila.

Quando você enfileira o build, o arquivo de projeto implantará os scripts de banco de dados e os pacotes da Web da pasta de remoção de build especificada na propriedade OutputRoot .

Conclusão

Este tópico descreveu como publicar recursos de implantação, como pacotes da Web e scripts de banco de dados, de um build anterior específico usando o modelo de implantação de arquivo de projeto dividido. Ele explicou como substituir a propriedade OutputRoot e como incorporar a lógica de implantação em uma definição de build do TFS.

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.

Anterior Avançar

Partilhar via