Automatizando a geração de pacotes com o Jenkins

Dependendo da empresa em que você trabalha, o processo de geração de pacotes de uma aplicação pode ir do mais simples, como a execução de um único comando de build, até o mais complexo, envolvendo diversas equipes e muitos processos de controle.

Com o passar do tempo, muitos perceberam a importância dessa fase do projeto e hoje temos várias ferramentas de build que facilitam a geração de pacotes, assim como o próprio deploy. No Java, as ferramentas mais famosas são o Ant, Maven e Gradle, cada uma com suas vantagens e desvantagens.

O Maven e o Gradle são, hoje em dia, os mais utilizados, visto que além de gerenciar o projeto, também controlam as dependências. Mas independentemente de qual das três será utilizada, o Jenkins consegue se comunicar com ela e orquestrar todos os passos necessários para criar o pacote de uma aplicação.

O Jenkins C.I. é uma aplicação web de Integração Contínua que pode ser instalada em qualquer máquina e serve, principalmente, para executar os testes e criar os artefatos de um projeto de software.

Ela nasceu a partir de outra solução bem conhecida, o Hudson, que começou como uma ferramenta open source, mas, em 2010, a Oracle passou a ser a responsável pelo seu desenvolvimento.

Neste momento, alguns programadores da equipe aceitaram ir para a Oracle continuar com o projeto, porém, outros, em 2011, decidiram seguir por outro caminho e evoluir a ferramenta de forma open source, adotando o nome Jenkins.

Hoje, ambas são bastante utilizadas no mercado e fáceis de usar, pois com apenas alguns cliques você, seu chefe, um analista de teste ou de implantação pode criar um pacote do sistema sem a necessidade de executar comandos no console ou abrir uma IDE.

A Integração Contínua representa um conjunto de práticas que permitem que um sistema seja compilado, testado e construído em um ambiente separado e independente do de desenvolvimento. Ela permite que as mudanças que acontecem no código sejam integradas ao sistema mais rapidamente e de forma contínua, pois possui ferramentas, como o Jenkins e o Hudson, que automatizam as tarefas de todo esse processo.

As vantagens de não gerar os pacotes do projeto manualmente são várias, principalmente quando as equipes envolvidas no sistema são grandes e o ciclo de entregas é curto. No entanto, mesmo quando a equipe é pequena, a automatização ainda pode executar tarefas repetitivas e que tomariam tempo do desenvolvedor, permitindo que ele foque no que realmente importa.

O Jenkins, por exemplo, possibilita que você gere pacotes a cada intervalo predeterminado de tempo, a cada commit no código ou simplesmente quando desejar, ou seja, você define a maneira que melhor se adequa na sua empresa.

Mas como nem tudo é perfeito, automatizar também tem suas desvantagens. Quando você automatiza processos, algumas pessoas da sua equipe e da sua empresa podem não ficar felizes, justamente por pensarem que estão “tirando” o trabalho delas.

Isso acontece com frequência em empresas que já têm um fluxo de deploy estabelecido onde, por exemplo, os desenvolvedores enviam o pacote para outra equipe, responsável por implantá-los nos servidores.

Provavelmente, obstáculos surgirão para que a automatização não aconteça, entretanto, é importante ter consciência de que esse esforço valerá a pena e que ninguém precisa ser mandado embora por causa do Jenkins.

A partir dela as equipes de implantação poderão se dedicar mais à manutenção dos servidores e escalabilidade do sistema, planejando maneiras mais eficientes e rápidas de fazer o deploy da aplicação.

Outro fator que atrapalha a automatização desse processo é a falta de confiança da empresa em seus desenvolvedores. Algumas não dão acesso aos programadores para instalarem aplicações nos ambientes de teste, muitas vezes desmotivando qualquer iniciativa que busque facilitar o processo.

Felizmente, todos esses problemas podem ser resolvidos com uma boa análise das necessidades do sistema, dos ambientes e dos usuários que, no fim, só querem ver as funcionalidades que eles pediram o mais rápido possível no ar.

A partir do que foi comentado, vamos abordar neste artigo a situação de uma empresa que deseja aprimorar seu processo de geração de pacotes, analisando para isso como ela trabalha atualmente e que opções temos disponíveis para alcançar a automatização desta etapa.

Analisando um processo manual de geração de pacotes

Suponha que você trabalha numa empresa que tenha um sistema web em Java de compra coletiva. A empresa tem equipes de desenvolvimento, QA, implantação e de negócios, sendo esta última a que conversa com os clientes e cria os requisitos do sistema.

Vocês utilizam Scrum, com sprints de três semanas, e SCM Subversion 1.7 como repositório do código, onde o trunk contém o código que está em desenvolvimento e, para cada entrega de versão, uma branch é criada.

Lá também tem três ambientes com o sistema instalado: dev, QA e produção, cada um com seu banco de dados MySQL e o servidor Tomcat. Além disso, scripts de banco são criados apenas para inserir configurações, já que o sistema utiliza o Hibernate para gerenciar as criações e atualizações de tabelas.

SCM é o acrônimo para Source Code Management e consiste na gestão do armazenamento e das alterações realizadas em um software. Para a gestão de alterações no código, existem ferramentas de controle de versão como o Subversion (SVN), CVS, Git, entre outros, que automatizam o armazenamento, recuperação, log e merge das mudanças.

Voltando ao exemplo, todo o processo de geração e deploy do pacote do sistema é feito de forma manual, dependendo completamente das pessoas da equipe.

Neste cenário foi definido que, no fim da Sprint, determinado desenvolvedor deve gerar o pacote a partir do trunk em sua própria máquina e colocá-lo em um servidor FTP para que um analista de implantação possa instalá-lo no ambiente de QA e, caso houvesse script de banco, ele também possa executá-lo.

Já a instalação no ambiente de dev é de responsabilidade da equipe de desenvolvimento, que normalmente gera e instala o pacote poucos dias antes de acabar a sprint, para validar e fazer alguns testes integrados antes de ir para QA. Depois de uma semana de testes no ambiente de QA e de tudo funcionando, os analistas de QA solicitam à equipe de implantação que instale o mesmo pacote no ambiente de produção e o processo termina.

Talvez você esteja pensando que o processo definido pela empresa está muito bom, e que atende perfeitamente às necessidades de todos os envolvidos nos projetos. Infelizmente, o que foi descrito é o fluxo perfeito e que com o tempo acabará se tornando raro.

Normalmente, quando o pacote vai para o QA, bugs são encontrados e novos pacotes com correções devem ser gerados. Assim, o deploy pode demorar ainda mais, visto que primeiro o desenvolvedor precisa enviar um e-mail solicitando à equipe de implantação uma nova instalação em QA.

Depois esta precisa avisar o horário de deploy para a equipe de QA, para evitar que alguém esteja testando algo no momento da instalação, e aí sim, finalmente, instala-se o novo pacote no servidor.

Ressalta-se ainda que durante a fase de testes essa situação se repetirá diversas vezes, sempre tomando tempo de várias pessoas, que neste cenário estão envolvidas em todas as partes do processo.

Outro problema que podemos perceber é que, como o processo de instalação é trabalhoso, os próprios desenvolvedores acabam utilizando menos o ambiente de dev (também chamado de ambiente de integração), já que alguém terá de parar para gerar o pacote e fazer o deploy.

Diante disso, a equipe de QA sofre com a espera de todo o fluxo de deploy quando precisa retestar a correção de um bug.

Já os implantadores ficam recebendo várias requisições de instalação de pacotes em QA e ainda precisam gerenciar o melhor horário para fazê-las. Isso sem contar que eles ainda têm o ambiente de produção para cuidar.

Agora, será que precisa ser assim mesmo? Por que não gastar um tempo conversando com as equipes para definir um processo mais eficiente e menos manual de entrega de pacotes?" [...] continue lendo...