Quando falam sobre Entrega Contínua, um dos testes que tanto Martin Fowler quanto Jez Humble mencionam com frequência é o teste do “lança-chamas”. Funciona assim: Jez irá dizer “quanto tempo levaria para para o seu programa subir e rodar se eu e o Martin entrássemos armados com lança-chamas e machados e começássemos a atacar os seus servidores”?

A resposta, é claro, deve ser: “oh, aproximadamente uma hora – logo depois que apagássemos o incêndio, limpássemos a bagunça, encontrássemos novos servidores, os ligássemos e entrássemos em contato com os melhores advogados para que eles te processassem por crime de danos materiais”. Na maioria das vezes, esse não é o caso, uma vez que o deployment é com frequência um processo todo manual, com o cara que é encarregado de fazer a instalação seguindo uma lista de instruções escrita em um documento do Word. E o que é uma lista de instruções? Um programa de computador. Levante a mão agora todos os que gostam de escrever documentos de Word. Ok, agora levante a mão todos que gostam de escrever programas de computador. Na sua imaginação, poderá ver uma sala cheia de pessoas votando por escrever código, então por que preferimos escrever documentos de Word quando temos a oportunidade de escrever um script de instalação? É muito mais divertido, produtivo e econômico escrever scripts que façam o deployment para nós em segundos, do que escrever documentos de Word e então fazer cada deployment nós mesmos.

Supondo que a sua sala de servidores foi destruída, vamos considerar então o que você precisa para que o seu programa passe a funcionar novamente. Para começar, você precisará de uma máquina com alguns ajustes comuns. Estou simplificando aqui, mas você provavelmente irá precisar de:

• algumas contas de usuário.
• um pouquinho de redes (saber onde o seu DNS está etc.)
• a versão certa do Java
• um Subversion (ou outro) cliente de controle de versão
• Tomcat (ou outro servidor)
• alguns arquivos de configuração
• seu arquivo WAR

Agora isso deve ser tão simples quanto ter uma imagem básica de um drive ou uma máquina virtual, ligar, inicializar e executar o script de deployment.

Se você já leu alguma vez o livro de Jez Humble e David Farley, Continous Delivery, irá saber que uma das coisas mais importantes que eles defendem é que, ao configurar o seu processo de deployment, é necessário armazenar seus arquivos de configuração em seu sistema de controle de versão. Isso me parece uma daquelas ideias óbvias e úteis que você só faz quando alguém te lembra. Isso normalmente significa apenas os arquivos de configuração do seu aplicativo, mas deve se referir também aos arquivos de configuração do seu servidor.

Outra coisa que irá perceber sobre o livro é que, apesar de ser cheio de boas ideias, ele é intencionalmente reduzido em exemplos práticos de código¹. Se você leu meus artigos, irá se recordar que menciono atualizar a maior parte dos meus arquivos de configuração do Tomcat em um ponto ou outro; por exemplo, para acrescentar detalhes de fontes de dados ou a configuração de um SSL. Com isso em mente, o restante deste artigo leva em conta as ideias de Jez e David e demonstra como criar um script simples de instalação para meu servidor Tomcat.

Se você baixar a versão candidate do Tomcat e descompactar o arquivo tar/zip, irá perceber que ele possui um diretório conf, então a primeira coisa a se fazer é acrescentar esse diretório ao controle de versão e apagá-lo dos binários compactados do tomcat. Agora você pode checar os arquivos conf, modificá-los, acrescentar SSL, um usuário admin, uma fonte de dados MySQL ou o que quer que você deseje. Não se esqueça de verificá-los novamente.

A próxima coisa a se fazer é colocar os diretórios dos binários restantes em um servidor FTP² em um lugar seguro e acessível.

Tudo que temos agora é uma configuração básica guardada em dois lugares convenientes. Estes podem ser recombinados para criar um servidor funcional.

A grande ideia aqui é que, apesar de essas duas coisas poderem ser facilmente executadas manualmente, a melhor maneira é fazê-la automaticamente através de um script simples.

#!/bin/sh
# 
echo Running Tomcat install Script

TOMCAT_VERSION=apache-tomcat-7.0.33-blog

# The FTP server holding the tomcat binaries
SERVER=<your server name>
TOMCAT_LOCATION=/Public/binaries/
SERVER_USER=<your FTP User Name>
SERVER_PASSWORD=<your FTP password>
CUT_DIRS=3

# The version control details
SVN_USER=<your Subversion username>
SVN_PASSWORD=<your Subversion Password>
SVN_URL=https:<the URL to your subversion repository>/Tomcat/apache-tomcat-7.0.33/conf

mkdir ../$TOMCAT_VERSION
pwd
echo changing directory
cd ../vim $TOMCAT_VERSION
pwd

wget -r -nH -nc --cut-dirs=$CUT_DIRS ftp://$SERVER_USER:$SERVER_PASSWORD@$SERVER$TOMCAT_LOCATION$TOMCAT_VERSION

echo ..
echo The directory looks like this:
ls
echo ..
echo Getting the config files from config..

svn --username=$SVN_USER --password=$SVN_PASSWORD co $SVN_URL

bin/startup.sh

# At this point handover to the application deploy script.

Em meu script, você irá ver que tudo que faço é utilizar três comandos simples. Primeiro utilizo wget para copiar os arquivos de meu servidor FTP para um novo servidor. O segundo comando é o svn co, que checa os arquivos de configuração do tomcat e o comando final que simplesmente inicia o servidor. O restante do script são apenas variáveis, comentários e “enchimento de linguiça”.

Agora, eu chuto que uma das razões pelas quais nós escrevemos tantos documentos de Word é pela possibilidade de acompanhar os passos. Então o truque final é permitir que o seu script seja a documentação ao também armazená-lo no controle de versão.

Aí está, uma forma simples de criar uma instalação de um servidor tomcat em segundos. Obviamente que o próximo passo seria o script de instalação chamar outro script que instalaria o seu aplicativo web no servidor, mas falaremos mais sobre isso em outra oportunidade.

____

¹Acho que a principal razão para não haver muitos exemplos concretos é pelo fato de que não há formas fixas, como uma estrutura de diretórios Maven, seja para criar servidores ou instalar aplicativos, uma vez que cada organização é diferente. Isso é uma coisa boa? Provavelmente não. Talvez devesse haver uma movimento para criar um “servidor padrão” que propusesse uma forma “padrão” de entregar o código.

²Este também poderia ser um servidor de arquivos, um SFTP ou um servidor web, e os binários do tomcat poderiam ser zipados ou descompactados.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.captaindebug.com/2013/01/super-fast-tomcat-installation-using.html#.UZq2OkBDu-R