Gestão de projetos e Integração Contínua com DevOps

Em artigo publicado na Edição 147 da Java Magazine, abordamos alguns dos pontos mais relevantes sobre desenvolvimento de software à luz de um paradigma que vem agitando o mercado no Brasil e no mundo: DevOps.

Naquela ocasião, algumas plataformas e ferramentas foram aplicadas – sempre sob a perspectiva ‘Dev’ desta nova cultura – na evolução de um projeto Java até o ponto ilustrado pela Figura 1. Por esta imagem, notamos que o trabalho que será realizado neste artigo será baseado em um projeto de software com uma estratégia sólida de versionamento de código, através do Git. Percebemos, ainda, que todo o seu ciclo de vida é gerenciado pelo Apache Maven, e que todo o trabalho é viabilizado a partir de uma IDE muito popular, o Eclipse.

Esta combinação de tecnologias, somada a uma equipe madura e bem qualificada, caracteriza um excelente ponto de partida na busca pela excelência na ‘camada’ de desenvolvimento, e nos permite abordar, ao longo do texto que se segue, aspectos fundamentais dentro de outra frente igualmente importante: operações.

Enquanto desenvolvimento é um termo que remete à construção do software em si, a frente de operações engloba aspectos vinculados à sua validação e utilização. Operadores estão, frequentemente, preocupados com o provisionamento e monitoramento de toda a infraestrutura necessária para todo o trabalho de criação e, também, homologação do software. São profissionais que atuam em contato tanto com a equipe de desenvolvimento quanto com clientes, com o principal objetivo de garantir a fluidez do projeto por meio do provisionamento de toda a infraestrutura necessária em ambas as pontas.

Figura 1. Situação do projeto tema ao início deste artigo.

A primeira questão que abordaremos neste artigo é a da Integração Contínua de software. Ao implementá-la, garantiremos que toda alteração realizada em nosso repositório de código resulte, imediatamente, em uma atividade de construção (build) do projeto com o objetivo de identificar os impactos das alterações submetidas, tanto sob a perspectiva da consistência estrutural (por meio de operações como a compilação de todo o código) quanto de comportamento (através da execução de suítes de testes automáticos).

A Integração Contínua de Software

Ao aplicar um conjunto de tecnologias no desenvolvimento de um projeto de software de qualidade em nosso ambiente de trabalho, estamos nos prevenindo contra uma série de fatores de risco. Um bom sistema de versionamento, por exemplo, nos torna capazes de administrar a evolução do código-fonte com muito mais precisão. Ao estabelecermos o Maven na gestão do ciclo de vida de um sistema, delegamos a execução de atividades como controle de dependências, compilação, empacotamento e testes – dentre outras – para uma plataforma de software, tornando-as muito menos propensas a falhas.

Entretanto, manter toda esta configuração distribuída, sob a responsabilidade individual de cada desenvolvedor no projeto, é insuficiente. É importante que essas mesmas características sejam espelhadas em um ambiente considerado oficial, do qual se possa extrair versões de um produto, submetê-las à avaliação de equipes de testes e, em última instância, aos próprios clientes. A integração contínua é o primeiro grande passo neste sentido, e é sobre isto que passaremos a conversar nesta seção.

Mas o que é integração contínua, afinal?

Integração contínua é um dos temas mais populares em Engenharia de Software na atualidade. Mas, afinal de contas, esta integração remete a que? E por que contínua? O que isto quer dizer? De que estamos falando, mais especificamente?

Estas podem ser perguntas recorrentes que, principalmente profissionais mais novatos – inundados por uma imensidão de novidades divulgada diariamente em nosso mercado – podem estar se fazendo. Vamos, então, avaliar o conceito por trás do tema.

Quando se fala em integração contínua (ou simplesmente CI), os holofotes estão direcionados essencialmente para o código-fonte. Integração, portanto, remete à prática de se avaliar os impactos diretos da incorporação de qualquer conteúdo, submetido por um desenvolvedor dentro de uma equipe, em um repositório de código-fonte centralizado.

A motivação para o surgimento desta prática é que, à medida que desenvolvedores trabalham para transformar documentação de requisitos – funcionais e não funcionais – em algo executável/concreto, é natural que colisões de código possam surgir. É bem provável que, em algum momento, um mesmo módulo de um projeto seja alterado, simultaneamente, por dois ou mais profissionais, e um episódio como esse pode, eventualmente, resultar em problemas.

A integração contínua atua exatamente antecipando tais situações, permitindo que o time reaja imediatamente e colabore para garantir uma evolução muito mais segura do produto. No trato popular, portanto, adotar integração contínua é simplesmente seguir a velha máxima de que ‘é melhor prevenir que remediar’.

E como faço para começar a trabalhar com integração contínua?

A natureza preventiva da prática de integração contínua parece boa, não? Agora que vimos o que significa integrar software continuamente, a próxima pergunta que o leitor pode estar se fazendo é como, enfim, torná-la realidade em seu projeto. Para respondê-la, configuraremos este processo sobre o repositório de código-fonte de nosso projeto tema.

Inicialmente, devemos identificar, dentre as principais soluções disponíveis no mercado, a que melhor atenda nossas necessidades. Ao fazer isso, o próximo passo é decidirmos sobre qual infraestrutura nosso processo de integração contínua será instalado. Por fim, deve-se verificar os passos a executar, para implementar e publicar este serviço.

Antes de darmos o primeiro passo, porém, é importante que destaquemos dois aspectos fundamentais associados à prática de integração contínua: o primeiro, de ordem cultural, trata de uma questão comportamental; enquanto o segundo, mais técnico, refere-se ao risco da dependência tecnológica.

Boas práticas de versionamento: não represe seu código!

Uma das más práticas que podem prejudicar o andamento de qualquer projeto de software – principalmente aqueles que buscam se beneficiar das vantagens da cultura DevOps – é o represamento de código em repositório privado. Tal comportamento pode resultar no acúmulo de muito conteúdo na máquina do desenvolvedor e, ao mesmo tempo, ignorar muitas submissões de código que outros desenvolvedores podem estar realizando, diariamente, conforme o projeto evolui. Quando, finalmente, uma submissão de todo o material acumulado é feita, haverá grande probabilidade do surgimento de conflitos de versão, sendo necessário um bom tempo até que tudo seja resolvido e, enfim, volte-se a ter código estável.

A dica que fica, portanto, é submeter código o mais frequentemente possível, de modo a evitar este tipo de pesadelo que, quase sempre, prejudica consideravelmente o desempenho da equipe. O consenso atual entre profissionais ativos de comunidades e fóruns pela Internet é de que o intervalo razoável para cada submissão é de uma vez ao dia.

O cliente para versionamento de código não deve ser impedimento para o processo

Outra característica que devemos sempre ter em mente diz respeito ao cliente de versionamento que utilizamos. Como sabemos, o Git é o sistema em si e temos, à nossa disposição, algumas implementações populares como GitHub e Bitbucket, que o oferecem como um serviço. Em nosso projeto tema, decidimos utilizar o GitHub, mas é importante que o leitor saiba que não há, nesta escolha, nenhuma especificidade de natureza técnica; tudo o que estamos fazendo através do GitHub é, também, absolutamente possível de ser realizado com Bitbucket ou qualquer serviço similar. Este é um detalhe fundamental para quem deseja manter seus projetos flexíveis, pois a independência de plataformas abre espaço para mudanças estruturais sem comprometer a sua essência." [...] continue lendo...