DevOps – Integração Contínua

hudson-500x253

Hoje vamos falar sobre integração contínua e como exemplo prático utilizarei o jenkins, fazendo um processo bem simples de integração contínua.

Integração contínua é o processo pelo qual os desenvolvedores integram os seus códigos frequentemente para verificação de problemas de integração e integridade com o código principal ou novos códigos que outros desenvolvedores criaram.
Esse processo pode ser feito manualmente ou de forma automatizada, sendo que na minha visão a integração contínua só funciona na prática se o processo for automatizado, caso contrário o desenvolvedor acaba perdendo tempo no processo e acaba quebrando as regras e voltando ao processo anterior. E a ideia da integração contínua é otimizar o processo, não criar rotinas custosas.

No melhor dos mundos, a integração contínua deve ter os processos de controle de versão (acho que nem deveria citar esse pois todos deveriam utilizar controle de versão por padrão), build, teste e deploy automatizados.
A única parte que dá para conviver sem é a parte de automação de testes, desde que você tenha uma equipe de QA ou um processo de teste bem documentado. Com isso você pode implementar a integração contínua fazendo com que os novos códigos sejam carregados, o build seja verificado e o deploy seja feito em um ambiente de homologação.
Após os testes finalizados você consegue com um clique enviar o pacote para a produção. Esse é o processo que usamos aqui na empresa, deploy automático em homologação, validação manual e subida em produção com um clique.
Ainda chegaremos na automatização completa e volto aqui para falar dessa última fase do processo.

A equipe de desenvolvimento tem que estar bem alinhada com esse processo e testar minimamente o código antes de qualquer envio ao repositório principal pois qualquer envio pode fazer com que o sistema deixe de funcionar. Não podem existir envios com funcionalidades quebradas ou parcialmente finalizadas, a ideia do processo é enviar ao repositório principal sempre funcionalidades que possam ir para a produção.

Para esse artigo farei a conexão do jenkins no repositório do site no bitbucket (utilizo o bitbucket para controle de versão do site), o jenkins baixará o código modificado para um diretório local e depois vou configurar um processo de FTP para subida de um arquivo modificado.

Link para download: Jenkins

A instalação é bem simples e inicialmente podemos manter as configurações que já vem como padrão.

Considerando que instalamos em nossa máquina local, o jenkins funcionará no endereço http://localhost:8080/ e trará o site abaixo:

01_homeJenkins

Após a instalação vamos fazer a instalação dos plugins necessários para o nosso processo. Entrando em Gerenciar Jenkins -> Gerenciar plugins, podemos selecionar e instalar os plugins necessários. Vamos instalar os plugins “Bitbucket plugin” e “Publish over ftp”.

Em seguida faremos as configuração iniciais do git e do FTP, entrando em Gerenciar jenkins -> Configurar sistema. Temos que configurar o diretório que o git está instalado (Path to git executable) e adicionar as credenciais de FTP no box relacionado ao Publish over ftp.

Definidas as configurações iniciais partimos para a criação do job, clicando no item “Novo job” do menu. Iniciaremos com um projeto de software free-style, entrando na tela de configuração inicial do job, vamos configurar a parte de Gerenciamento de código fonte, Trigger de builds e Build.

No Gerenciamento de código fonte selecionamos Git e definimos as configurações como abaixo, onde nas credenciais você deve colocar as suas configurações para acesso ao bitbucket.

03_configs_bit

Em seguida vamos configurar para que o jenkins verifique o repositório principal a cada 15 minutos e em caso de alteração, baixe os arquivos e envie o arquivo teste_jenkins.txt via FTP.

04-1_configs_build_ftp

Na tela inicial do jenkins agora podemos ver o nosso novo job, status atual e executá-lo manualmente.

05_lista_jobs_cria_view

Agora vamos fazer o processo de integração contínua. Acessando a URL http://www.tinovacao.com/teste_jenkins.txt, verificamos que o arquivo não existe:

06-1_file_not_found

Faço a criação do arquivo teste_jenkins.txt, com o texto “v1”, efetuo o versionamento local e envio para o branch master no bitbucket. Após isso, aguardo no máximo 15 minutos (que foi o tempo que eu configurei para que o jenkins acesse o repositório e verifique se existem mudanças.

Após isso o job verifica a existência de mudanças no repositório, baixa a última versão e automaticamente sobe o arquivo no FTP. Se acessarmos a UTr novamente, veremos o conteúdo:

06-1_file_v1

Para verificar o log de execução do job podemos clicar sobre a execução que queremos e selecionar o item “Saída do console”:

07_saida_console

07-2_saida_console