Gerenciamento do ciclo de vida do aplicativo: Do desenvolvimento à produção

por Jason Lee

Este tópico ilustra como uma empresa fictícia gerencia a implantação de um aplicativo Web ASP.NET por meio de ambientes de teste, preparo e produção como parte de um processo de desenvolvimento contínuo. Ao longo do tópico, links são fornecidos para obter mais informações e instruções passo a passo sobre como executar tarefas específicas.

O tópico foi projetado para fornecer uma visão geral de alto nível para uma série de tutoriais sobre a implantação da Web na empresa. Não se preocupe se você não estiver familiarizado com alguns dos conceitos descritos aqui— os tutoriais a seguir fornecem informações detalhadas sobre todas essas tarefas e técnicas.

Observação

Para simplificar, este tópico não aborda a atualização de bancos de dados como parte do processo de implantação. No entanto, fazer atualizações incrementais para recursos de bancos de dados é um requisito de muitos cenários de implantação empresarial e você pode encontrar diretrizes sobre como fazer isso mais adiante nesta série de tutoriais. Para obter mais informações, consulte Implantando projetos de banco de dados.

Visão geral

O processo de implantação ilustrado aqui baseia-se no cenário de implantação da Fabrikam, Inc. descrito em Enterprise Web Deployment: Scenario Overview. Você deve ler a visão geral do cenário antes de estudar este tópico. Essencialmente, o cenário examina como uma organização gerencia a implantação de um aplicativo Web razoavelmente complexo, a solução do Contact Manager, por meio de várias fases em um ambiente empresarial típico.

Em um alto nível, a solução do Contact Manager passa por esses estágios como parte do processo de desenvolvimento e implantação:

1. Um desenvolvedor verifica algum código no TFS (Team Foundation Server) 2010.
2. O TFS compila o código e executa todos os testes de unidade associados ao projeto de equipe.
3. O TFS implanta a solução no ambiente de teste.
4. A equipe de desenvolvedores verifica e valida a solução no ambiente de teste.
5. O administrador do ambiente de preparo executa uma implantação "e se" no ambiente de preparo, para estabelecer se a implantação causará problemas.
6. O administrador do ambiente de preparo executa uma implantação dinâmica no ambiente de preparo.
7. A solução passa por testes de aceitação do usuário no ambiente de preparo.
8. Os pacotes de implantação da Web são importados manualmente para o ambiente de produção.

Esses estágios fazem parte de um ciclo de desenvolvimento contínuo.

Na prática, o processo é um pouco mais complicado do que isso, como você verá quando examinarmos cada estágio com mais detalhes. A Fabrikam, Inc. usa uma abordagem diferente para implantação para cada ambiente de destino.

O restante deste tópico examina estes estágios principais deste ciclo de vida de implantação:

• Pré-requisitos: como você precisa configurar sua infraestrutura de servidor antes de colocar sua lógica de implantação em vigor.
• Desenvolvimento e implantação iniciais: o que você precisa fazer antes de implantar sua solução pela primeira vez.
• Implantação a ser testada: como empacotar e implantar conteúdo em um ambiente de teste automaticamente quando um desenvolvedor verifica o novo código.
• Implantação no preparo: como implantar builds específicos em um ambiente de preparo e como executar implantações "e se" para garantir que uma implantação não cause problemas.
• Implantação em produção: como importar pacotes Web para um ambiente de produção quando a infraestrutura de rede impede a implantação remota.

Pré-requisitos

A primeira tarefa em qualquer cenário de implantação é garantir que sua infraestrutura de servidor atenda aos requisitos de suas ferramentas e técnicas de implantação. Nesse caso, a Fabrikam, Inc. configurou sua infraestrutura de servidor da seguinte maneira:

• O TFS está configurado para incluir uma coleção de projetos de equipe, controladores de build e agentes de build. Consulte Configuring Team Foundation Server for Automated Web Deployment para obter mais informações.
• O ambiente de teste é configurado para aceitar implantações remotas usando o Web Deployment Agent Service (o "agente remoto"), conforme descrito em Cenário: Configurando um ambiente de teste para implantação da Web e configurar um servidor Web para publicação de implantação da Web (agente remoto).
• O ambiente de preparo é configurado para aceitar implantações remotas usando o ponto de extremidade manipulador de implantação da Web, conforme descrito em Cenário: configurando um ambiente de preparo para implantação da Web e configurar um servidor Web para publicação de implantação da Web (manipulador de implantação da Web).
• O ambiente de produção é configurado para permitir que um administrador importe manualmente pacotes de implantação da Web para o IIS (Serviços de Informações da Internet), conforme descrito em Cenário: Configurando um ambiente de produção para implantação da Web e configurar um servidor Web para publicação de implantação na Web (implantação offline).

Desenvolvimento e implantação iniciais

Antes que a equipe de desenvolvimento da Fabrikam, Inc. possa implantar a solução do Contact Manager pela primeira vez, ela precisa executar estas tarefas:

• Crie um novo projeto de equipe no TFS.
• Crie os arquivos de projeto do Microsoft Build Engine (MSBuild) que contêm a lógica de implantação.
• Crie as definições de build do TFS que disparam os processos de implantação.

Criar um novo projeto de equipe

• O administrador do TFS, Rob Walters, cria um novo projeto de equipe para o aplicativo, conforme descrito em Criando um projeto de equipe no TFS. Em seguida, o desenvolvedor principal, Matt Hink, cria uma solução de esqueleto. Ele verifica seus arquivos no novo projeto de equipe no TFS, conforme descrito em Adicionar conteúdo ao controle do código-fonte.

Criar a lógica de implantação

Matt Hink cria vários arquivos de projeto personalizados do MSBuild, usando a abordagem de arquivo de projeto dividido descrita em Noções básicas sobre o arquivo de projeto. Matt cria:

• Um arquivo de projeto chamado Publish.proj que executa o processo de implantação. Esse arquivo contém destinos do MSBuild que criam os projetos na solução, criam pacotes Web e implantam os pacotes em um ambiente de servidor de destino.
• Arquivos de projeto específicos do ambiente chamados Env-Dev.proj e Env-Stage.proj. Elas contêm configurações específicas para o ambiente de teste e o ambiente de preparo, respectivamente, como cadeias de conexão, pontos de extremidade de serviço e os detalhes do serviço remoto que receberá o pacote da Web. Para obter diretrizes sobre como escolher as configurações certas para ambientes de destino específicos, consulte Configurar propriedades de implantação para um ambiente de destino.

Para executar a implantação, um usuário executa o arquivo Publish.proj usando o MSBuild ou o Team Build e especifica o local do arquivo de projeto específico do ambiente relevante (Env-Dev.proj ou Env-Stage.proj) como um argumento de linha de comando. Em seguida, o arquivo Publish.proj importa o arquivo de projeto específico do ambiente para criar um conjunto completo de instruções de publicação para cada ambiente de destino.

Observação

A maneira como esses arquivos de projeto personalizados funcionam é independente do mecanismo usado para invocar o MSBuild. Por exemplo, você pode usar a linha de comando do MSBuild diretamente, conforme descrito em Noções básicas sobre o arquivo de projeto. Você pode executar os arquivos de projeto de um arquivo de comando, conforme descrito em Criar e executar um arquivo de comando de implantação. Como alternativa, você pode executar os arquivos de projeto de uma definição de build no TFS, conforme descrito em Criando uma definição de build que dá suporte à implantação.
Em cada caso, o resultado final é o mesmo: o MSBuild executa o arquivo de projeto mesclado e implanta sua solução no ambiente de destino. Isso fornece uma grande flexibilidade na forma como você dispara seu processo de publicação.

Depois de criar os arquivos de projeto personalizados, Matt os adiciona a uma pasta de solução e os verifica no controle do código-fonte.

Criar definições de build

Como uma tarefa de preparação final, Matt e Rob trabalham juntos para criar três definições de build para o novo projeto de equipe:

• DeployToTest. Isso cria a solução do Gerenciador de Contatos e a implanta no ambiente de teste sempre que ocorre um marcar.
• DeployToStaging. Isso implanta recursos de um build anterior especificado no ambiente de preparo quando um desenvolvedor enfileira o build.
• DeployToStaging-WhatIf. Isso executa uma implantação "e se" no ambiente de preparo quando um desenvolvedor enfileira o build.

As seções a seguir fornecem mais detalhes sobre cada uma dessas definições de build.

Implantação em teste

A equipe de desenvolvimento da Fabrikam, Inc. mantém ambientes de teste para realizar uma variedade de atividades de teste de software, como verificação e validação, testes de usabilidade, testes de compatibilidade e testes ad hoc ou exploratórios.

A equipe de desenvolvimento criou uma definição de build no TFS chamada DeployToTest. Essa definição de build usa um gatilho de integração contínua, o que significa que o processo de build é executado sempre que um membro da equipe de desenvolvimento da Fabrikam, Inc. executa um marcar-in. Quando um build é disparado, a definição de build:

• Crie a solução ContactManager.sln. Isso, por sua vez, cria todos os projetos dentro da solução.
• Execute todos os testes de unidade na estrutura da pasta da solução (se a solução for compilada com êxito).
• Execute os arquivos de projeto personalizados que controlam o processo de implantação (se a solução for compilada com êxito e passar por testes de unidade).

O resultado final é que, se a solução for compilada com êxito e passar em testes de unidade, os pacotes Web e quaisquer outros recursos de implantação serão implantados no ambiente de teste.

Como funciona o processo de implantação?

A definição de build DeployToTest fornece estes argumentos para o MSBuild:

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

As propriedades DeployOnBuild=true e DeployTarget=package são usadas quando o Team Build compila os projetos dentro da solução. Quando o projeto é um projeto de aplicativo Web, essas propriedades instruem o MSBuild a criar um pacote de implantação da Web para o projeto. A propriedade TargetEnvPropsFile informa ao arquivo Publish.proj para onde encontrar o arquivo de projeto específico do ambiente a ser importado.

Observação

Para obter um passo a passo detalhado sobre como criar uma definição de build como esta, consulte Criando uma definição de build que dá suporte à implantação.

O arquivo Publish.proj contém destinos que criam cada projeto na solução. No entanto, ele também inclui lógica condicional que ignora esses destinos de build se você estiver executando o arquivo no Team Build. Isso permite que você aproveite a funcionalidade de build adicional que o Team Build oferece, como a capacidade de executar testes de unidade. Se o build da solução ou os testes de unidade falharem, o arquivo Publish.proj não será executado e o aplicativo não será implantado.

A lógica condicional é realizada avaliando a propriedade BuildingInTeamBuild . Essa é uma propriedade do MSBuild que é definida automaticamente como true quando você usa o Team Build para criar seus projetos.

Implantação para preparo

Quando um build atende a todos os requisitos da equipe de desenvolvedores no ambiente de teste, a equipe pode querer implantar o mesmo build em um ambiente de preparo. Os ambientes de preparo normalmente são configurados para corresponder às características do ambiente de produção ou "dinâmico" o mais próximo possível, por exemplo, em termos de especificações de servidor, sistemas operacionais e software e configuração de rede. Os ambientes de preparo geralmente são usados para teste de carga, teste de aceitação do usuário e revisões internas mais amplas. As compilações são implantadas no ambiente de preparo diretamente do servidor de build.

As definições de build usadas para implantar a solução no ambiente de preparo, DeployToStaging-WhatIf e DeployToStaging, compartilham estas características:

• Eles não constroem nada. Quando Rob implanta a solução no ambiente de preparo, ele deseja implantar uma compilação específica existente que já foi verificada e validada no ambiente de teste. As definições de build só precisam executar os arquivos de projeto personalizados que controlam o processo de implantação.
• Quando Rob dispara um build, ele usa os parâmetros de build para especificar qual build contém os recursos que deseja implantar do servidor de build.
• As definições de build não são disparadas automaticamente. Rob enfileira manualmente um build quando deseja implantar a solução no ambiente de preparo.

Esse é o processo de alto nível para uma implantação no ambiente de preparo:

1. O administrador do ambiente de preparo, Rob Walters, enfileira um build usando a definição de build DeployToStaging-WhatIf . Rob usa os parâmetros de definição de build para especificar qual build ele deseja implantar.
2. A definição de build DeployToStaging-WhatIf executa os arquivos de projeto personalizados no modo "e se". Isso gera arquivos de log como se Rob estivesse executando uma implantação ao vivo, mas não faz nenhuma alteração no ambiente de destino.
3. Rob examina os arquivos de log para verificar os efeitos da implantação no ambiente de preparo. Em particular, Rob deseja marcar o que será adicionado, o que será atualizado e o que será excluído.
4. Se Rob estiver satisfeito que a implantação não fará alterações indesejáveis em recursos ou dados existentes, ele enfileirará um build usando a definição de build DeployToStaging .
5. A definição de build DeployToStaging executa os arquivos de projeto personalizados. Eles publicam os recursos de implantação no servidor Web primário no ambiente de preparo.
6. O controlador WFF (Web Farm Framework) sincroniza os servidores Web no ambiente de preparo. Isso disponibiliza o aplicativo em todos os servidores Web no farm de servidores.

Como funciona o processo de implantação?

A definição de build DeployToStaging fornece esses argumentos para o MSBuild:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

A propriedade TargetEnvPropsFile informa ao arquivo Publish.proj para onde encontrar o arquivo de projeto específico do ambiente a ser importado. A propriedade OutputRoot substitui o valor interno e indica o local da pasta de build que contém os recursos que você deseja implantar. Quando Rob enfileira o build, ele usa a guia Parâmetros para fornecer um valor atualizado para a propriedade OutputRoot .

Observação

Para obter mais informações sobre como criar uma definição de build como esta, consulte Implantar um build específico.

A definição de build DeployToStaging-WhatIf contém a mesma lógica de implantação que a definição de build DeployToStaging . No entanto, ele inclui o argumento adicional WhatIf=true:

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

No arquivo Publish.proj , a propriedade WhatIf indica que todos os recursos de implantação devem ser publicados no modo "e se". Em outras palavras, os arquivos de log são gerados como se a implantação tivesse ido adiante, mas nada realmente foi alterado no ambiente de destino. Isso permite avaliar o impacto de uma implantação proposta, em particular, o que será adicionado, o que será atualizado e o que será excluído antes de realmente fazer alterações.

Observação

Para obter mais informações sobre como configurar implantações "e se", consulte Executando uma implantação "E se".

Depois de implantar seu aplicativo no servidor Web primário no ambiente de preparo, o WFF sincronizará automaticamente o aplicativo em todos os servidores no farm de servidores.

Observação

Para obter mais informações sobre como configurar o WFF para sincronizar servidores Web, consulte Criar um Farm de Servidores com o Web Farm Framework.

Implantação em produção

Quando um build foi aprovado no ambiente de preparo, a equipe da Fabrikam, Inc. pode publicar o aplicativo no ambiente de produção. O ambiente de produção é onde o aplicativo fica "ativo" e atinge seu público-alvo de usuários finais.

O ambiente de produção está em uma rede de perímetro voltada para a Internet. Isso é isolado da rede interna que contém o servidor de build. A administradora do ambiente de produção, Lisa Andrews, deve copiar manualmente os pacotes de implantação da Web do servidor de build e importá-los para o IIS no servidor Web de produção primário.

Esse é o processo de alto nível para uma implantação no ambiente de produção:

1. A equipe de desenvolvedores aconselha Lisa que um build está pronto para implantação em produção. A equipe aconselha Lisa sobre o local dos pacotes de implantação da Web dentro da pasta drop no servidor de build.
2. Lisa coleta os pacotes web do servidor de build e os copia para o servidor Web primário no ambiente de produção.
3. Lisa usa o Gerenciador do IIS para importar e publicar os pacotes web no servidor Web primário.
4. O controlador WFF sincroniza os servidores Web no ambiente de produção. Isso disponibiliza o aplicativo em todos os servidores Web no farm de servidores.

Como funciona o processo de implantação?

O Gerenciador do IIS inclui um Assistente para Importar Pacote de Aplicativo que facilita a publicação de pacotes Web em um site do IIS. Para obter um passo a passo sobre como executar esse procedimento, consulte Instalando manualmente pacotes Web.

Conclusão

Este tópico forneceu uma ilustração do ciclo de vida da implantação para um aplicativo Web de escala empresarial típico.

Este tópico faz parte de uma série de tutoriais que fornecem diretrizes sobre vários aspectos da implantação de aplicativos Web. Na prática, há muitas tarefas e considerações adicionais em cada estágio do processo de implantação e não é possível cobri-las todas em um único passo a passo. Para obter mais informações, consulte estes tutoriais:

• Implantação da Web na Empresa. Este tutorial fornece uma introdução abrangente às técnicas de implantação da Web usando o MSBuild e a Ferramenta de Implantação da Web do IIS (Implantação da Web).
• Configurando ambientes de servidor para implantação da Web. Este tutorial fornece diretrizes sobre como configurar ambientes de servidor Windows para dar suporte a vários cenários de implantação.
• Configurando o Team Foundation Server para implantação da Web automatizada. Este tutorial fornece diretrizes sobre como integrar a lógica de implantação aos processos de build do TFS.
• Implantação avançada da Web corporativa. Este tutorial fornece diretrizes sobre como atender a alguns dos desafios de implantação mais complexos que as organizações enfrentam.

Anterior