A Integração Contínua é uma técnica popular no desenvolvimento de software. Nas conferências, muitos desenvolvedores falam sobre como a utilizam, e as ferramentas de Integração Contínua são comuns na maioria das organizações de desenvolvimento. Mas todos nós sabemos que qualquer técnica decente precisa de um programa de certificação – e, felizmente, existe. Desenvolvido por um dos principais especialistas em entrega contínua e devops, é conhecido por ser extremamente rápido para administrar e ainda muito perspicaz para seus resultados. Embora seja bastante maduro, não é tão conhecido como deveria ser. Então, como fã da técnica, acho importante compartilhar esse programa de certificação com meus leitores. Você está pronto para ser certificado em Integração Contínua? E como você vai lidar com a verdade chocante que realizar o teste vai revelar?

Até agora, meus leitores regulares estão se perguntando se eles se depararam com um artigo de paródia [1] e, sim, eu estou me divertindo um pouco com meu teaser de abertura. Mas, como qualquer boa piada, há um núcleo importante de verdade enterrado nele. Há um teste notavelmente bom para Integração Contínua apropriada que foi criado por Jez Humble – e ele certamente é um perito líder em Entrega Contínua. É também um teste rápido, ele muitas vezes administra isso com o seu público durante suas conversas. O único problema é que eu nunca o ouvi referir-se a ele como um teste de certificação – o que apenas mostra sua falta de visão para esquemas de ganhar dinheiro.

Ele geralmente começa o processo de certificação pedindo ao público para levantar as mãos se eles fazem Integração Contínua. Geralmente, a maioria do público levanta as mãos.

Ele então pede para manter as mãos para cima se todos em suas equipes fazem commits e pushes para uma linha principal compartilhada (geralmente compartilhada no master no git), pelo menos diariamente.

Mais da metade das mãos se abaixam.

Ele então pede para manter as mãos para cima se cada commit causa uma build e teste automatizado. Metade das mãos restantes são abaixadas.

Finalmente, ele pergunta se, quando a compilação falha, geralmente volta ao verde dentro de dez minutos. [2]

Com essa última pergunta, apenas restam algumas mãos. Essas são as pessoas que passam no teste de certificação.

É um conjunto simples de perguntas, mas ele chega ao cerne do que é a Integração Contínua. A ideia é que ninguém esteja trabalhando em uma base de código que se desvia significativamente da de outra pessoa. Integração Contínua significa que a equipe sabe o que o estado atual do código verdadeiramente é, evitamos grandes fusões de risco e as pessoas podem refatorar tanto quanto elas precisem.

A razão pela qual tantas pessoas levantam suas mãos no início é a visão comum de que a Integração Contínua significa executar algum “Continuous Integration Server” contra seus vários recursos. Mas a Integração Contínua – como descrita originalmente e nomeada por Kent Beck como parte da ExtremeProgramming – não tem nada a ver com ferramentas. No início, era um fluxo de trabalho humano, e Jim Shore fez um excelente argumento de que deveria ser isso. A ideia de executar um processo do daemon contra um repositório de código-fonte veio mais tarde e, embora seja útil, só é Integração Contínua se for executada em uma linha principal compartilhada que as pessoas se comprometem a fazer todos os dias. Executar tal daemon de outra forma, como em cada FeatureBranch, é Daemonic Continuous Integration que degrada o nome [3], resultando em um fluxo de trabalho que não lhe dá os benefícios que fazem toda a coisa valer o esforço.

Leitura adicional

Para mais detalhes sobre Integração Contínua, veja meu artigo principal, que, mesmo escrito em 2006, ainda é um sólido resumo e definição da técnica. Jez explica por que a Integração Contínua é uma base para a Entrega Contínua. Ele afirma as três perguntas no FAQ naquela página. Paul Duvall escreveu o livro definitivo sobre Integração Contínua. Assista a Jez administrando o teste de certificação no GOTO Chicago em 2014 (infelizmente, não havia câmera na plateia).

Agradecimentos

Todo o crédito das três perguntas vão para Jez, de cujas conversas eu sempre gostei. Uma conversa com Paul Hammant provocou-me para vir com o termo Daemonic Continuous Integration, que eu espero que “pegue” e comece a ser usado para esse pedaço particularmente irritante de culto de carga.

Notas

1: Em geral, eu não sou um fã de esquemas de certificação de software, como eles geralmente falham no CertificationCompetenceCorrelation.

2: Para esta etapa, “verde” conta como passando commit build, normalmente compilação e testes unitários. Enquanto normalmente esperamos que um full DeploymentPipeline seja executado do lançamento para produção, um repositório deve ser bom para os desenvolvedores trabalharem depois que o commit build estiver verde. Você deve ter um commit build que não leve mais de dez minutos, que rapidamente o corrija e volte a executar o commit build que funciona se a correção for fácil. Se você não pode consertar e obtém um commit build dentro de dez minutos, então você deve reverter para a última build verde.

3: O problema da Daemonic Continuous Integration leva algumas pessoas a usar o nome Trunk-Based Development, argumentando que SemanticDiffusion tornou o termo “Continuous Integration” inútil. Embora eu entenda a sua visão, creio que não devemos ceder à difusão semântica, em vez disso precisamos continuar trabalhando para reexplicar o significado apropriado da Integração Contínua, assim como deveríamos com outros termos sob esse tipo de ataque semântico (tais como “agile” e “refactoring”).

***

Martin Fowler faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://martinfowler.com/bliki/ContinuousIntegrationCertification.html.