Olá, pessoal!

No artigo de hoje vamos ver como fazer um deploy automatizado usando o Jenkins. Como assim? Vamos entender a seguir.

Entendendo o contexto

Não é muito difícil encontrar algum programador que tenha algum dia trabalhado em um projeto onde o deploy da aplicação era feito manualmente, ou seja, gerar o .war localmente e copiar para o servidor remoto via FTP, ssh etc. E sabemos o quanto é demorado fazer isso por mais que tenhamos uma boa conexão de Internet, já que o .war tende a aumentar à medida que nosso projeto vai evoluindo e permanecer fazendo isso manualmente tende a demorar mais ainda o tempo de cópia do .war para um ambiente remoto.

Já fiz muito isso e em alguns projetos já levei até 30 minutos esperando o .war ser copiado. E quando vejo, a alteração que acabei de fazer não foi junto naquele .war porque fiz o build antes de ter salvo a alteração. O que fazer? Build e aguardar por mais 30 minutos. E aí já foi uma hora do seu dia fazendo algo operacional e que custa caro.

Deploy automatizado/ delivery continuous

É aí que entra o deploy automatizado. No Jenkis, além de oferecer o build automatizado, há suporte através de plugin para que possamos pegar o artefato (.war/ear) gerado no build e colocar em um servidor remoto (jetty, tomcat, glasshfish etc) de maneira automatizada, ou seja, quem vai copiar e colar o arquivo será a própria ferramenta e certamente será mais rápido que copiar da sua máquina local para o servidor remoto. E outra coisa, tudo isso fazendo hotdeploy, ou seja, não é preciso parar o Server para colocar .war, mas é recomendado fazer quando a copia .war for muito grande, e se ela não termina antes do tomcat, jetty etc verificar se algo mudou, o arquivo será corrompido. E o que acontece com sua aplicação? Down. E teremos que subir manualmente.

Claro que tudo depende do seu ambiente… Se é de DEV, não tem problema fazer hotdeploy; mas se for um ambiente de PROD, você arriscaria fazer um hotdeploy? A resposta seria: depende. Normalmente não vamos querer fazer uma release para PROD no horário comercial ou de mais acesso da aplicação por uma questão de segurança e disponibilidade do serviço.

Na prática

Considerando que você já tem o Jenkins rodando e um projeto, vamos direto ao ponto. O que você precisa?

Vá em manager jenkins >> manager plugins e instale o seguinte plugin Copy Artifact Plugin e o Deploy Plugin. O primeiro tem como objetivo copiar o artefato, ou seja, o .war. Então vamos configurar que após o build success do projeto X vamos copiar o artefato e deployed no servidor TomCat. Quem faz o deploy é o segundo plugin. Instale os plugins. Escolha a opção install without restart.

Criando um novo Job

Considerado que você já tem um projeto configurado no Jenkins, você não precisa fazer nada nesse projeto, apenas crie um novo Job do tipo Freestyle. A seguir o meu:

O nome do projeto foi omitido.

Configurando o Job

Em Project Name você informa de qual projeto você que copiar o artefato. Verá que ao digitar o nome do projeto/job já existente, o Jenkins vai oferecer um autocomplete. Em seguida, informamos que queremos apenas .war, senão ele vai copiar tudo que tiver no outro projeto, ou seja, se tiver um .ear ele seria copiado por exemplo.

Deploy no TomCat

Agora vamos fazer o deploy no TomCat.

Aqui dizemos aos Jenkins o que fazer depois que ele copiar o artefato, e estamos dizendo para fazer um deploy. Para aparecer esse form, clique em add post-build action e escolha deploy artficats. Na imagem acima informamos o tipo de arquivo que será deployed, o servidor, o contexto, usuário, password e a url onde está o servidor.

Claro que o usuário precisa ter acesso ao servidor. No caso do tomcat, vá em conf/tomcatusers.xml e verifique se o usuário está lá. E certamente não vai estar com role para execução de script, portanto adicione manager-script, ficando assim:

<role rolename=”manager-script”/>
<user username=”camilo” password=”xxxx” roles=” admin,manager,manager-gui,manager-script,manager-jmx”/>

Isso é requerido, senão o plugin não vai conseguir realizar o deploy. O .war será colocado dentro de webapps do servidor tomcat. Quando o build terminar com sucesso, acesse sua aplicação. Se for local digite: http://localhost:8080/nomeDaSuaApplicacao.

Lembre-se que se definiu o Context, informe o nome depois da / senão acesse pelo mesmo nome do arquivo .war.

Meu case

Antes de implementar o deploy automatizado aqui no projeto o tempo de cópia de um artefato para o ambiente de dev remoto era de 30 minutos incluindo o stop e start do tomcat. Após o deploy automatizado caímos para 13 segundos, veja:

Note: Se você não especifica, o Context será o nome do arquivo .war.

Nota importante: se o Jenkins e sua aplicação são deployed no mesmo servidor, você não tem como fugir do hotdeploy, já que ao fazer um restart vai cair todos os serviços que estão rodando no Server.

Vou ficando por aqui e espero que tenham gostado do artigo.

Abraços!