DevOps: Como adequar seu processo de CI a essa nova cultura

Artigo no estilo Mentoring

Em artigo publicado na edição 149 da Java Magazine, aprendemos a construir um ambiente de integração contínua baseado em Maven e Jenkins, suportado por medições estáticas de qualidade a partir de uma plataforma chamada Sonar Qube. O objetivo principal de todo o artigo foi, a partir de um tutorial prático, introduzir algumas das ferramentas mais populares do mercado contemporâneo para o desenho de processos dinâmicos de desenvolvimento de software, com foco na prática DevOps.

O resultado desse trabalho, que servirá de ponto de partida para este artigo, foi resumido na Figura 1. Nela, vemos a máquina de desenvolvimento, configurada com uma IDE (neste caso, o Eclipse), Git e Maven. Uma vez que parte do código do software tenha sido escrito, ele passa por uma validação local, realizada a partir da execução de testes unitários. Então, esse mesmo código é submetido a um controle local e, a seguir, remoto, de versão.

Quando esse repositório remoto, hospedado em uma conta GitHub, recebe esse conteúdo, dispara uma requisição de execução do primeiro de uma cadeia de jobs em um servidor de integração contínua (Jenkins), hospedado em um gear OpenShift. A partir desse primeiro job, todos os demais são executados sequencialmente, e o resultado final é um build completo, associado a uma análise estática da qualidade do projeto. Essa análise é feita por uma instância do Sonar Qube, também hospedada em um gear OpenShift.

No artigo de hoje, retomaremos muitos dos pontos que acabamos de citar, estendendo-os e refinando-os para oferecer, ao final, um processo alinhado aos principais fundamentos e práticas do que hoje se rotula como DevOps no mercado de TI. Obviamente, por ser esse um tema ainda em franca evolução, a visão levantada ao longo deste material será, naturalmente, fonte para uma série de discussões complementares. Saiba que esse não é um material definitivo sobre DevOps, mas uma introdução que visa trazer ao leitor informações que o ajudem a adotá-lo em seu cotidiano.

Entendendo o nosso ponto de partida

O projeto-guia de todo este artigo, bem como daquele publicado na edição 149, consiste em uma aplicação Java, stand-alone, para o cálculo de resistências elétricas a partir de um padrão de faixas e cores. Esse projeto apresenta, além do código principal, testes unitários que validam todos os requisitos levantados. Todo esse conteúdo está devidamente salvo em um repositório público no GitHub, podendo ser visto e baixado pelo leitor a partir da referência que se encontra na seção Links.

A primeira grande decisão que tivemos de tomar, antes mesmo de iniciar a escrita do software em si, relacionou-se à plataforma de gerenciamento do ciclo de vida desse projeto. Esse é um ponto bastante importante, e qualquer escolha que se tome nesse instante refletirá, posteriormente, em todo o andamento do trabalho.

Por ciclo de vida de projeto, devemos entender atividades que vão desde o gerenciamento de dependências do produto até operações básicas como compilação, teste, empacotamento, implantação e, inclusive, execução.

Nesse contexto, o Maven ainda é uma ferramenta muito popular. É fato que, há alguns anos, vem disputando espaço com outras plataformas bem interessantes, como o Gradle, mas seu índice de utilização ainda é muito expressivo, sobretudo, no mundo corporativo. Ao final do artigo, na seção Links, recomendamos uma leitura complementar sobre esse tema.

Foi essa grande popularidade, aliada à maior familiaridade de toda a comunidade com o seu modelo de configuração, que nos levou a adotar o Maven em nosso projeto.

Outro aspecto que já encontraremos pré-configurado antes do início deste texto é um processo de build em um servidor Jenkins, rodando sobre a plataforma OpenShift. O cenário de partida é algo como o ilustrado na Figura 2. Perceba que, atualmente, temos apenas um processo de build, composto por quatro jobs. O primeiro passo dessa cadeia envolve uma limpeza de toda a árvore de diretórios do projeto, eliminando dali quaisquer resquícios de material gerado em builds anteriores. Em seguida, por meio do job intitulado devmediadevops_test_job, executa-se a fase de testes do ciclo de vida padrão do Maven. Nesse momento, são colocados para rodar todos os testes unitários do projeto, que validarão toda a lógica principal do produto. Ao ordenarmos que a fase test seja processada, o Maven executará, também, todas as fases configuradas como anteriores a essa, e o resultado dessa operação será a validação, a compilação e, por fim, o processamento de todos os testes unitários do projeto.

Caso todos os testes executem com sucesso, o Jenkins passará a executar o job seguinte, de nome devmediadevops_package_measure_job. O objetivo dessa tarefa é realizar o empacotamento de todos os módulos do projeto, gerar o pacote da aplicação em si e, em seguida, medir a qualidade de todo o material por meio de uma análise do Sonar Qube.

O empacotamento é realizado, novamente, a partir do Maven, por meio do comando mvn package -DskipTests=true -f $OPENSHIFT_DATA_DIR/workspace/sonar/devops/pom.xml. Note que, nesse momento, os testes são ignorados, uma vez que já os executamos no job anterior. Portanto, na tarefa de nome devmediadevops_package_measure_job, estamos apenas compilando o projeto novamente, empacotando-o em seguida. A ação seguinte, configurada como um passo de pós-build nesse job, consiste na comunicação remota com o servidor em que o Sonar Qube está instalado (via SSH) para, então, disparar a execução da análise do projeto. O resultado é publicado em uma página gerada e alimentada pelo Sonar, e que tem a aparência e estrutura exibidas na Figura 3.

Refinando o processo de integração contínua

Como acabamos de ver na seção anterior, o projeto original conta com apenas um processo de build. Um detalhe que não foi citado até aqui, mas que precisamos introduzir neste momento, é que essa cadeia de jobs é disparada automaticamente, sempre que um novo commit é realizado no repositório remoto.

Este processo automático é viabilizado a partir da utilização de um recurso chamado web hook, criado e administrado por meio da interface web do GitHub. Essa é a forma oferecida para contornar uma limitação imposta pela empresa, de não permitir conexões remotas via SSH com seus servidores. Os detalhes sobre o funcionamento desse mecanismo podem ser ...