Compartilhar via

Diferenças de configuração comuns entre desenvolvimento e produção (VB)

  • Artigo

por Scott Mitchell

Baixar PDF

Em tutoriais anteriores, implantamos nosso site copiando todos os arquivos pertinentes do ambiente de desenvolvimento para o ambiente de produção. No entanto, não é incomum que haja diferenças de configuração entre ambientes, o que exige que cada ambiente tenha um arquivo de Web.config exclusivo. Este tutorial examina as diferenças de configuração típicas e analisa estratégias para manter informações de configuração separadas.

Introdução

Os dois últimos tutoriais percorreram a implantação de um aplicativo Web simples. O tutorial Implantando seu site usando um cliente FTP mostrou como usar um cliente FTP autônomo para copiar os arquivos necessários do ambiente de desenvolvimento para produção. O tutorial anterior, Implantando seu site usando o Visual Studio, analisou a implantação usando a ferramenta Copiar Site do Visual Studio e a opção Publicar. Em ambos os tutoriais, cada arquivo no ambiente de produção era uma cópia de um arquivo no ambiente de desenvolvimento. No entanto, não é incomum que os arquivos de configuração no ambiente de produção sejam diferentes daqueles no ambiente de desenvolvimento. A configuração de um aplicativo Web é armazenada no Web.config arquivo e normalmente inclui informações sobre recursos externos, como servidores de banco de dados, Web e email. Ele também explica o comportamento do aplicativo em determinadas situações, como o curso de ação a ser tomada quando ocorre uma exceção sem tratamento.

Ao implantar um aplicativo Web, é importante que as informações de configuração corretas acabem no ambiente de produção. Na maioria dos casos, o Web.config arquivo no ambiente de desenvolvimento não pode ser copiado para o ambiente de produção como está. Em vez disso, uma versão personalizada do Web.config precisa ser carregada para produção. Este tutorial examina brevemente algumas das diferenças de configuração mais comuns; ele também resume algumas técnicas para manter diferentes informações de configuração entre os ambientes.

Diferenças de configuração típicas entre os ambientes de desenvolvimento e produção

O Web.config arquivo inclui uma variedade de informações de configuração para um aplicativo ASP.NET. Algumas dessas informações de configuração são as mesmas, independentemente do ambiente. Por exemplo, as configurações de autenticação e as regras de autorização de URL escritas nos Web.config elementos e <authorization> do <authentication> arquivo geralmente são as mesmas, independentemente do ambiente. Mas outras informações de configuração, como informações sobre recursos externos, normalmente diferem dependendo do ambiente.

As cadeias de conexões de banco de dados são um exemplo primo de informações de configuração que diferem com base no ambiente. Quando um aplicativo Web se comunica com um servidor de banco de dados, ele deve primeiro estabelecer uma conexão e isso é obtido por meio de um cadeia de conexão. Embora seja possível codificar o banco de dados cadeia de conexão diretamente nas páginas da Web ou no código que se conecta ao banco de dados, é melhor colocá-lo Web.config<connectionStrings> no elemento para que as informações de cadeia de conexão fiquem em um único local centralizado. Geralmente, um banco de dados diferente é usado durante o desenvolvimento do que é usado na produção; consequentemente, as informações de cadeia de conexão devem ser exclusivas para cada ambiente.

Observação

Os tutoriais futuros exploram a implantação de aplicativos controlados por dados. Nesse ponto, nos aprofundaremos nas especificidades de como as cadeias de conexão de banco de dados são armazenadas no arquivo de configuração.

O comportamento pretendido dos ambientes de desenvolvimento e produção difere substancialmente. Um aplicativo Web no ambiente de desenvolvimento está sendo criado, testado e depurado por um pequeno grupo de desenvolvedores. No ambiente de produção, esse mesmo aplicativo está sendo visitado por muitos usuários simultâneos diferentes. ASP.NET inclui vários recursos que ajudam os desenvolvedores a testar e depurar um aplicativo, mas esses recursos devem ser desabilitados por motivos de desempenho e segurança quando estiverem no ambiente de produção. Vamos examinar algumas dessas definições de configuração.

Definições de configuração que afetam o desempenho

Quando uma página ASP.NET é visitada pela primeira vez (ou pela primeira vez depois de alterada), sua marcação declarativa deve ser convertida em uma classe e essa classe deve ser compilada. Se o aplicativo Web usar a compilação automática, a classe code-behind da página também precisará ser compilada. Você pode configurar uma variedade de opções de compilação por meio do Web.config elemento do <compilation>arquivo.

O atributo de depuração é um dos atributos mais importantes no <compilation> elemento . Se o debug atributo for definido como "true", os assemblies compilados incluirão símbolos de depuração, que são necessários ao depurar um aplicativo no Visual Studio. Mas os símbolos de depuração aumentam o tamanho do assembly e impõem requisitos de memória adicionais ao executar o código. Além disso, quando o debug atributo é definido como "true", qualquer conteúdo retornado por WebResource.axd não é armazenado em cache, o que significa que sempre que um usuário visita uma página, ele precisará baixar novamente o conteúdo estático retornado por WebResource.axd.

Observação

WebResource.axd é um manipulador HTTP interno introduzido no ASP.NET 2.0 que os controles de servidor usam para recuperar recursos inseridos, como arquivos de script, imagens, arquivos CSS e outros conteúdos. Para obter mais informações sobre como WebResource.axd funciona e como você pode usá-lo para acessar recursos inseridos de seus controles de servidor personalizados, consulte Acessando recursos inseridos por meio de uma URL usando WebResource.axd.

O <compilation> atributo do debug elemento geralmente é definido como "true" no ambiente de desenvolvimento. Na verdade, esse atributo deve ser definido como "true" para depurar um aplicativo Web; se você tentar depurar um aplicativo ASP.NET do Visual Studio e o atributo estiver definido como "false", o debug Visual Studio exibirá uma mensagem explicando que o aplicativo não pode ser depurado até que o debug atributo seja definido como "true" e se oferecerá para fazer essa alteração para você.

Você nunca deve ter o debug atributo definido como "true" em um ambiente de produção devido ao seu impacto no desempenho. Para obter uma discussão mais completa sobre este tópico, consulte a postagem no blog de Scott Guthrie, Don't Run Production ASP.NET Applications With debug="true" Enabled.

Erros personalizados e rastreamento

Quando ocorre uma exceção sem tratamento em um aplicativo ASP.NET, ela surge até o runtime em que uma das três coisas acontece:

  • Uma mensagem de erro de runtime genérico é exibida. Esta página informa ao usuário que houve um erro de runtime, mas não fornece detalhes sobre o erro.
  • Uma mensagem de detalhes de exceção é exibida, que inclui informações sobre a exceção que acabou de ser gerada.
  • Uma página de erro personalizada é exibida, que é uma página ASP.NET que você cria que exibe qualquer mensagem desejada.

O que acontece diante de uma exceção sem tratamento depende da Web.config seção do <customErrors>arquivo.

Ao desenvolver e testar um aplicativo, ele ajuda a ver detalhes de qualquer exceção no navegador. No entanto, mostrar detalhes da exceção em um aplicativo em produção é um risco potencial à segurança. Além disso, não é lisonjeira e faz com que seu site pareça não profissional. Idealmente, no caso de uma exceção sem tratamento, um aplicativo Web no ambiente de desenvolvimento mostrará os detalhes da exceção enquanto o mesmo aplicativo em produção mostrará uma página de erro personalizada.

Observação

A configuração de seção padrão <customErrors> mostra a mensagem de detalhes da exceção somente quando a página está sendo visitada por meio do localhost e mostra a página de erro de runtime genérico caso contrário. Isso não é o ideal, mas é assegurar que o comportamento padrão não revele detalhes da exceção para visitantes não locais. Um tutorial futuro examina a <customErrors> seção mais detalhadamente e mostra como ter uma página de erro personalizada mostrada quando ocorre um erro na produção.

Outra ASP.NET recurso útil durante o desenvolvimento é o rastreamento. O rastreamento, se habilitado, registra informações sobre cada solicitação de entrada e fornece uma página da Web especial, Trace.axd, para exibir detalhes recentes da solicitação. Você pode ativar e configurar o rastreamento por meio do <trace> elemento em Web.config.

Se você habilitar o rastreamento, verifique se ele está desabilitado na produção. Como as informações de rastreamento incluem cookies, dados de sessão e outras informações potencialmente confidenciais, é importante desabilitar o rastreamento na produção. A boa notícia é que, por padrão, o rastreamento está desabilitado e o Trace.axd arquivo só pode ser acessado por meio do localhost. Se você alterar essas configurações padrão no desenvolvimento, verifique se elas estão desativadas na produção.

Técnicas para manter informações de configuração separadas

Ter diferentes definições de configuração nos ambientes de desenvolvimento e produção complica o processo de implantação. Nos dois tutoriais anteriores, o processo de implantação envolvia copiar todos os arquivos necessários do desenvolvimento para a produção, mas essa abordagem só funcionará se as informações de configuração forem as mesmas em ambos os ambientes. Há uma variedade de técnicas para implantar um aplicativo com informações de configuração variadas. Vamos catalogar algumas dessas opções para aplicativos Web hospedados.

Implantando manualmente o arquivo de configuração do ambiente de produção

A abordagem mais simples é manter duas versões do Web.config arquivo: uma para o ambiente de desenvolvimento e outra para o ambiente de produção. A implantação de um site em produção envolve a cópia de todos os arquivos para o servidor de produção no ambiente de desenvolvimento , exceto para o Web.config arquivo. Em vez disso, o arquivo específico Web.config do ambiente de produção seria copiado para produção.

Essa abordagem não é muito sofisticada, mas é fácil de implementar porque as informações de configuração são alteradas com pouca frequência. Ele funciona melhor para aplicativos com uma pequena equipe de desenvolvimento hospedada em um único servidor Web e cujas informações de configuração são raramente alteradas. Ele é mais utilizável ao implantar manualmente os arquivos de aplicativo usando um cliente FTP autônomo. Ao usar a ferramenta Copiar Site do Visual Studio ou a opção Publicar, primeiro você precisará trocar o arquivo específico Web.config da implantação pelo específico de produção antes da implantação e, em seguida, trocá-los novamente após a conclusão da implantação.

Alterar a configuração durante o processo de build ou implantação

As discussões até agora assumiram um processo de build e implantação ad hoc. Muitos projetos de software maiores têm processos mais formalizados que usam ferramentas de software livre, domésticas ou de terceiros. Para esses projetos, você provavelmente pode personalizar o processo de build ou implantação para modificar adequadamente as informações de configuração antes que elas sejam enviadas por push para a produção. Se você criar seu aplicativo Web usando MSBuild, NAnt ou alguma outra ferramenta de build, provavelmente poderá adicionar uma etapa de build para modificar o Web.config arquivo para incluir as configurações específicas de produção. Ou o fluxo de trabalho de implantação pode se conectar programaticamente ao servidor de controle do código-fonte e recuperar o arquivo apropriado Web.config .

A abordagem real para obter as informações de configuração apropriadas para produção varia muito com base em suas ferramentas e fluxo de trabalho. Dessa forma, não nos aprofundaremos mais neste tópico. Se você estiver usando uma ferramenta de build popular, como MSBuild ou NAnt, poderá encontrar artigos de implantação e tutoriais específicos para essas ferramentas por meio de uma pesquisa na Web.

Gerenciando diferenças de configuração por meio do projeto de implantação da Web Add-In

Em 2006, a Microsoft lançou o Projeto de Desenvolvimento para a Web Add-In para Visual Studio 2005. Um Add-In para Visual Studio 2008 foi lançado em 2008. Essa Add-In permite que ASP.NET desenvolvedores criem um Projeto de Implantação web separado junto com seu projeto de aplicativo Web que, quando criado, compila explicitamente o aplicativo Web e copia os arquivos para implantar em um diretório de saída local. O Projeto de Aplicativo Web usa o MSBuild nos bastidores.

Por padrão, o arquivo do ambiente de Web.config desenvolvimento é copiado para o diretório de saída, mas você pode configurar o Projeto de Implantação da Web para personalizar o

informações de configuração que são copiadas para esse diretório das seguintes maneiras:

  • Por meio Web.config da substituição da seção de arquivo, na qual você especifica a seção a ser substituída e um arquivo XML que contém o texto de substituição.
  • Fornecendo um caminho para um arquivo de origem de configuração externa. Com essa opção selecionada, o Projeto de Implantação da Web copia um arquivo específico Web.config para o diretório de saída (em vez do Web.config arquivo usado no ambiente de desenvolvimento).
  • Adicionando regras personalizadas ao arquivo MSBuild usado pelo Projeto de Implantação da Web.

Para implantar o aplicativo Web, crie o Projeto de Implantação da Web e copie os arquivos da pasta de saída do projeto para o ambiente de produção.

Para saber mais sobre como usar o Projeto de Implantação da Web marcar este artigo Projetos de Implantação na Web da edição de abril de 2007 da Revista MSDN ou consulte os links na seção Leitura Adicional no final deste tutorial.

Observação

Não é possível usar o Projeto de Implantação da Web com o Desenvolvedor do Visual Web porque o Projeto de Implantação da Web é implementado como um Add-In do Visual Studio e as edições do Visual Studio Express (incluindo o Visual Web Developer) não dão suporte a Suplementos.

Resumo

Os recursos externos e o comportamento de um aplicativo Web em desenvolvimento normalmente são diferentes de quando o mesmo aplicativo está em produção. Por exemplo, cadeias de conexão de banco de dados, opções de compilação e o comportamento quando ocorre uma exceção sem tratamento geralmente diferem entre ambientes. O processo de implantação deve acomodar essas diferenças. Como discutimos neste tutorial, a abordagem mais simples é copiar manualmente um arquivo de configuração alternativo para o ambiente de produção. Soluções mais elegantes são possíveis ao usar o projeto de implantação da Web Add-In ou com um processo de build ou implantação mais formalizado que pode acomodar essas personalizações.

Programação feliz!

Leitura Adicional

Para obter mais informações sobre os tópicos discutidos neste tutorial, consulte os seguintes recursos:

AnteriorAvançar