Olá pessoal, tudo bem?
Esse objetivo é o primeiro do tópico Deploying web applications and services, os últimos 20% da certificação. Nesse objetivo vamos ver como fazer o deploy de aplicações web usando XCopy, criar um IIS Install Package, automatizar deploys com TFS ou Build Server e fazer deploy para web farms.
Fazendo Deploy De Aplicações Web Usando XCopy
O jeito mais fácil de fazer o deploy de uma aplicação para um ambiente de produção é manualmente. Seja via FTP ou conexão remota, chamamos de XCopy quando você copia os arquivos da sua máquina local para uma de produção. XCopy, na verdade, é um comando DOS para transferência de vários arquivos ao mesmo tempo. A sintaxe dele é a seguinte:
xcopy /I /S /E <source path> <destination path>
A opção /I diz que você copiando uma pasta, a /S que você quer copiar todos os subdiretórios e a /E que as subpastas devem ser copiadas mesmo que vazias. Há também a opção /d, que indica que somente os arquivos novos atualizados ou novos devem ser copiados.
Configurando O IIS
Na primeira vez que você copiar os arquivos do seu site para seu servidor, você vai precisar configurá-lo no IIS, que é o servidor de hospedagem para aplicações no Windows. Você precisa dizer ao IIS qual é a pasta do seu site e como ele vai estar disponível para os usuários.
Assumindo que você tenha uma aplicação em C:\Development\MyApp e quer movê-la para C:\inetpub\wwwroot\MyApp, o primeiro passo é fazer o XCopy:
xcopy /I /S C:\Development\MyApp C:\inetpub\wwwroot\MyApp
Para fazer a configuração no IIS, você abre o IIS Manager e a opção de adicionar um website. Você precisa dar um nome e apontar a localização da pasta (nesse caso, C:\inetpub\wwwroot\MyApp). Normalmente também você deve colocar um host name para o IIS mapear os requests HTTP na porta 80.
No exemplo abaixo, alteramos a porta para 81 e deixamos o host name em branco, para podermos acessar o site somente pela porta. A configuração fica assim:
Acessando http://localhost:81 no browser, o ISS já consegue mapear o request e mandá-lo para a aplicação.
Preparando Um Website Para Deploy
Quando os arquivos são atualizados, o IIS detecta as modificações e começa a atualizar o site. Isso gera erros nos requests feitos enquanto a aplicação está parcialmente atualizada.
Para evitar que os usuários vejam uma tela de erro, você pode colocar um arquivo com o nome App_offline.htm no root do website. O IIS então vai mostrar esse HTML ao invés da mensagem de erro. Após a atualização de todos os arquivos, você deve apagar esse arquivos para o IIS voltar a processar os requests.
Outro ponto é que o App Domain pode restartar várias vezes enquanto os arquivos estão sendo atualizados. Você pode configurar o atributo waitChangeNotification no seu web.config para especificar o número de segundos de espera antes que o App Domain restarte:
Ferramental Para Deploys XCopy
Usar o XCopy pela linha de comando não é a melhor maneira de você copiar seus arquivos. O Visual Studio oferece algumas ferramentas para auxiliar o processo de deploy, e vamos analisar uma delas agora: a Copy Website Tool. Nela você pode:
- Copiar arquivos de código para o target especificado;
- Copiar arquivos usando os protocolos suportados: IIS local, IIS remoto, FTP e HTTP (comente com FrontPage Server Extensions);
- Escolher quais arquivos quer sincronizar do seu código para o target;
- Automaticamente copiar o arquivo App_offline.htm quando o deploy começar e removê-lo quando terminar.
Criando Um IIS Install Package
Lançado em 2009, o Web Deploy permite que você crie um pacote de deploy que além dos arquivos do seu site contém configurações de banco de dados, IIS, registro, assemblies para carregar no GAC, etc.
O Web Deployment Framework simplifica o processo podendo ser utilizado via Visual Studio, IIS, prompt de comando e Windows PowerShell. Também ajuda em ambientes complexos como web farm, onde você sincroniza diferentes servidores usando o Web Deploy.
Para o exame, lembre-se: Web Deployment Framework é a ferramenta ideal para deploys complexos.
Automatizando Deploys Com TFS Ou Build Server
Por motivos fora do escopo do exame, você deve saber como automatizar o deploy de uma aplicação com TFS ou Build Server. É importante conhecer os conceitos por trás disso, como Continuous Integration e Continuous Deployment com testes de unidade e integração, mas estes não são prováveis de estarem no exame.
Você pode automatizar o deploy de uma aplicação no Azure de forma bem fácil. Há uma opção “Set up deployment from source control” que implementa o conceito de Continuous Deployment: cada check-in no controle de versão dispara um deploy automaticamente. O repositório pode ser TFS ou Git.
É possível também fazer isso on-premises com TFS. Você pode buildar sua aplicação via linha de comando com MSBuild da seguinte forma:
MSBuild /target:Publish /p:PublishDir=\\myserver\drops\
Depois, editando a Build Definition no TFS, você pode adicionar um comando de Publish para publicar o pacote no Azure.
É importante entender que existem duas ferramentas TFS: uma on-premises e uma na nuvem, atualmente chamada VSTS.
Fazendo Deploys Para Web Farms
Para essa seção, você deve entender os conceitos de scale up e scale out.
Scale up é quando você aumenta a capacidade do seu hardware para fazer uma melhora de performance na sua aplicação. Isso é feito quando você coloca mais memória RAM, troca de processador ou coloca um SSD no lugar do seu HD. Porém, além de ser caro, melhoras no hardware tem o limite do próprio hardware.
Aí entra o conceito de scale out, onde você usa múltiplos servidores para hospedar sua aplicação ao invés de melhorar um. Juntos, eles formam o que chamamos de web farm ou ambiente distribuído. Um load balancer é necessário para “espalhar” os requests entre os servidores da forma mais eficiente possível.
Porém, um trabalho extra é necessário para sua aplicação poder ser hospedada numa web farm. Normalmente você configura 1 servidor, depois cria as aplicações no IIS de todos os outros com exatamente as mesmas configurações.
Outro ponto de preocupação é a session, que são dados do usuário gravados na memória. Com web farm, requests subsequentes de um mesmo usuário podem cair em várias máquinas diferentes, o que pode impossibilitar o uso de session. Para resolver esse problema, você precisa mover os dados da sessão para uma máquina externa ou até um banco de dados. Há 4 tipos de session states:
- InProc: valor padrão, onde os dados da session são gravados na memória;
- StateServer: guarda os dados da session em um processo separado chamado ASP.NET state service;
- SQLServer: guarda os dados da session num banco de dados SQL Server;
- Off: desabilita a session
Você também pode escolher ativar session affinity, onde todos os requests de um usuário vão cair no mesmo servidor, garantindo que os dados da session estarão na memória. Porém, nem todos os load balancers suportam isso.
Chegamos ao final desse objetivo.
Obrigado pela leitura e fique de olho no próximo post, que será sobre o objetivo Choose a deployment strategy for a Windows Azure web application.
Até mais!