O que é integração contínua (CI)?

A maioria dos desenvolvimentos de software hoje é feita em equipes que trabalham em um ou mais repositórios de código gerenciados em um sistema de controle centralizado de versões. Desenvolvedores individuais trabalham nas áreas de código que exigem alterações e devem decidir quando confirmar suas alterações no sistema de controle.

Às vezes, as alterações de código são fáceis e introduzem poucos riscos, portanto, o desenvolvedor pode fazer as edições e se comprometer com um baixo risco de interferir no que os colegas de equipe estão trabalhando.

Mas e se a equipe estiver trabalhando em um recurso maior que exigirá vários dias, semanas ou até meses de desenvolvimento? Quando é apropriado verificar essas alterações de código no sistema de controle de versões? Além disso, o que acontece quando esse código é verificado para garantir que o código integrado desenvolvido pela equipe se integre sem erros de compilação ou outros defeitos de funcionalidade?

Por que você precisa de integração contínua (CI)
Uma abordagem intuitiva é separar esse trabalho em ramificações de controle de versões separadas. As equipes decidem se devem usar uma única ramificação de recursos ou criar várias ramificações para cada desenvolvedor.

Embora intuitivo, esse modo de trabalhar não é o ideal. Cada ramificação de recursos possui alterações que divergem do tronco principal de desenvolvimento. Se essas ramificações de recursos forem usadas por longos períodos, a integração pode ser difícil, demorada na resolução de conflitos e propensa a erros.

As equipes maiores, que buscam desenvolver e implantar recursos rapidamente, procuraram uma nova abordagem em que as alterações são integradas com frequência e, em seguida, têm sua compilação e funcionalidade validadas pelo sistema de controle de versões. Isso agora é conhecido como integração contínua (CI) .

Definição
A integração contínua é uma filosofia de codificação e um conjunto de práticas relacionadas que orientam as equipes de desenvolvimento a implementar pequenas alterações e fazer check in de código para repositórios de controle de versões com frequência.

O sistema de controle de versões resolve dois grande problema do trabalho colaborativo: como compartilhar as informações de forma a ter a última versão válida e ainda saber quem fez as alterações; e como prevenir que os desenvolvedores refaçam o trabalho já desenvolvido.

Como a maioria dos aplicativos modernos exige o desenvolvimento de código em diferentes plataformas e ferramentas, a equipe precisa de um mecanismo para integrar e validar suas alterações. O objetivo técnico da integração contínua é estabelecer uma maneira consistente e automatizada de criar, empacotar e testar aplicativos. Com a consistência do processo de integração, as equipes têm maior probabilidade de cometer alterações de código com maior frequência, o que leva a uma melhor colaboração e qualidade de software.

Como funciona na prática
A integração contínua é uma filosofia de desenvolvimento apoiada por processos automatizados de construção de software. Ao praticar CI, os desenvolvedores submetem seu código ao sistema de controle de versões frequentemente. A maioria das equipes tem um padrão mínimo de confirmação de código pelo menos diariamente, podendo haver múltiplas integrações por dia. Quando os desenvolvedores trabalham em ciclos de consolidação mais curtos, é menos provável que vários desenvolvedores editem o mesmo código e exijam uma mesclagem ao fazer o commit.

A lógica por trás disso é que é mais fácil identificar defeitos e outros problemas de qualidade de software, e  reduzir problemas de integração e permite que um time desenvolva software coeso mais rapidamente, já que as correções são implementados em períodos mais curtos.

As equipes que implementam a integração contínua geralmente começam com definições de configuração e práticas de controle de versões. E usam diferentes técnicas para controlar quais recursos e códigos estão prontos para produção. Preferem confirmar o código em uma única ramificação ou tronco de desenvolvimento. Se as ramificações de recursos forem usadas,  preferem que elas tenham vida curta e sejam mescladas ao ramo principal com frequência.

Algumas equipes também usam sinalizadores de recursos, um mecanismo de configuração para ativar ou desativar recursos e códigos em tempo de execução. Os recursos que ainda estão em desenvolvimento são agrupados com sinalizadores de recursos no código, implantados n a ramificação principal para produção e desativados até que estejam prontos para serem usados.

O próprio processo de construção é automatizado empacotando todo o software, banco de dados e outros componentes. Por exemplo, se você estivesse desenvolvendo um aplicativo Java, o IC empacotaria todos os arquivos estáticos do servidor da Web, como HTML, CSS e JavaScript, juntamente com o aplicativo Java e quaisquer scripts de banco de dados.

A maioria das ferramentas de CI permite que os desenvolvedores iniciem as compilações sob demanda, acionadas por confirmações de código no repositório de controle de versões ou em um agendamento definido. As equipes precisam discutir o cronograma de criação que funciona melhor para o tamanho da equipe, o número de confirmações diárias esperadas e outras considerações de aplicativos. Uma prática recomendada é garantir que os commits e builds sejam rápidos; caso contrário, isso pode impedir o progresso de equipes que tentam codificar rapidamente.

Todo esse fluxo de trabalho é chamado de pipeline de CI .

Desenvolvimento e teste usando integração contínua (CI)
Depois que um pipeline de CI é introduzido, ele estabelece um novo fluxo de trabalho para os desenvolvedores. Eles editam código em seu editor ou em seu próprio ambiente “local”. Idealmente, eles também têm um ambiente de tempo de execução em seu ambiente local e podem executar alguns testes básicos de funcionalidade. 

Com esses testes básicos validados, eles podem confirmar o código. Uma plataforma de CI, como Jenkins ou Travis, pode acionar uma compilação que empacota todos os elementos de código em um ou mais componentes construídos. A plataforma de CI pode, então, executar qualquer ferramenta de análise de código estático e informar aos desenvolvedores se houve alguma falha na construção.

Se forem detectadas falhas, os membros da equipe devem agir rapidamente para pesquisar e resolver o problema, pois um pipeline de desenvolvimento com falhas pode interromper as atividades de desenvolvimento de toda a equipe. Muitas equipes rastreiam as métricas de captura nas taxas de sucesso e falha de compilação e usam esses dados para identificar melhorias no processo de desenvolvimento.

Uma vez que o software é empacotado, as ferramentas de CI podem ajudar a entregar o software construído em um ambiente de entrega direcionado, acionar quaisquer serviços necessários para a entrega, como reiniciar servidores de aplicativos, e iniciar testes automatizados. Essas etapas de entrega são comumente conhecidas como entrega contínua , e as funções de teste que são integradas no  pipeline de integração e entrega contínua (CI/CD) são partes de testes contínuos .

Equipes que praticam CI/CD podem oferecer recursos e aprimoramentos aos usuários mais rapidamente. A automação e o fluxo de trabalho reduzem a codificação e os defeitos funcionais. Esse tipo de fluxo de trabalho também aumenta a colaboração entre a equipe e, com frequência, gera soluções mais inteligentes e inovadoras. E tudo começa com integração contínua (CI).

 

(*) Isaac Sacolick é o autor de Driving Digital: The Leader’s Guide to Business Transformation through Technology, que abrange muitas práticas, como Agile, DevOps e Ciência de Dados, essenciais para programas de Transformação Digital bem-sucedidos. Sacolick é também um blogueiro de longa data, autor do blog Social, Agile and Transformation, colaborador da CIO.com , e presidente da StarCIO.