Maturidade da Integração Contínua

Há 15 anos Martin Fowler publicou Continuous Integration, artigo seminal da Integração Contínua. Alguns meses depois, foi lançado o CruiseControl, primeiro servidor de Integração Contínua. Hoje no mundo, apenas 50% das empresas possuem Integração Contínua, número baixo levando-se em conta a redução de custos que toda automação traz.

Talvez as empresas estejam pensando apenas no investimento, sem uma visão muito clara do ROI. O esforço de implementação da automação pode ser recuperado nas atividades de build/deploy/teste em dois à quatro sprints. O retorno é especialmente grande em projetos longos.

Além da baixa adoção, a baixa maturidade também impede a completa capitalização das vantagens da Integração Contínua.

E ainda vem por aí Entrega Contínua, Deploy Contínuo e DevOps, práticas que se apoiam e vão além da Integração Contínua, mas para isso a fundação precisa estar firme…

Maturidade DevOps

Mas como se avalia a maturidade de um ambiente de Integração Contínua?

Como avaliar a maturidade em Integração Contínua da minha empresa?

Na OCTO costumamos avaliar a maturidade dos nossos clientes com base em uma matriz, adaptada do livro Continuous Delivery. Os autores propõe uma matriz de avaliação, com 5 níveis de maturidade (regressivo, repetível, consistente, gerenciado e otimizado) e sobre seis disciplinas:

  • Gerência de build e Integração Contínua;
  • Ambientes e deployment;
  • Gerência de releases e conformidade;
  • Testes;
  • Gerência de dados;
  • Gerência de configuração.

Após a avaliação com base na matriz, pode-se, por exemplo, chegar à conclusão que a empresa tem boa maturidade em “Ambientes e deployment”, criando e provisionando ambientes automaticamente, mas possui baixa maturidade em “Testes”, fazendo apenas testes manuais. Deve-se então planejar ações corretivas para nivelar as práticas que estão com baixa maturidade, que nesse caso seria começar a trabalhar com testes automatizados.

Quais são os componentes da Integração Contínua?

A Integração Contínua mínima, equivale ao nível “repetível” de maturidade, onde há automação do build, mas com processos bem simples, usando as poucas ferramentas:

  • Controle de Versão (Git, Mercurial, Subversion, etc.)
  • Servidor de Integração Contínua (Jenkins, TeamCity, etc.)
  • Ferramenta de automação de build (Maven, Gradle, etc.)
  • Testes Unitários (JUnit, TestNG, etc.)

Já no nível seguinte, “consistente“, há uma grande evolução nos processos, utilizando mais e mais os recursos das mesma ferramentas, e adicionando apenas mais uma:

  • Release Manager / ALM (Jira, Rally, VersionOne, etc.)

No topo da maturidade, os processos ficam mais sofisticados, buscando a melhoria contínua. Já o ferramental cresce bastante:

  • Repositório de Artefatos (Artifactory, Archiva, etc.)
  • Análise de Qualidade (SonarQube + NDepend + PMD + Checkstyle, etc.)
  • Testes Funcionais (Fitnesse, Cucumber, etc.)
  • Provisionamento e virtualização (Vagrant, Docker, etc.)
  • (o céu é o limite!)

Integração Contínua

O que a minha empresa deveria ganhar com a Integração Contínua?

No mínimo redução de custos. Mas há outros ganhos possíveis com o aumento da maturidade:

  • Redução de custos com a eliminação de tarefas manuais repetitivas – Infelizmente as pessoas repetem tarefas que poderiam ser automatizadas. O tempo da infra e dos desenvolvedores é valioso, e deveria ser usado para coisas mais importantes.
  • Redução de riscos
    • Defeitos detectados e corrigidos mais cedo – Os testes automatizados podem detectar bugs no momento em que foram introduzidos, ainda na fase de desenvolvimento, quando sua correção é mais barata. Outra vantagem é manter a base de código saudável, evitando que outros desenvolvedores parem de trabalhar porque alguém quebrou o código.
    • Medição da qualidade – Inspeções automatizadas podem manter sob controle aspectos de arquitetura, como complexidade ciclomática, que afeta diretamente a produtividade.
    • Reduzir suposições – Os ambientes de build e teste repetem suas ações sob condições conhecidas, reduzindo a influência de fatores externos, como setup de ambiente, ou dependências de software de terceiros.
  • Geração automática de artefatos – A qualquer momento deve haver um artefato disponível. Qualquer pessoa que precise fazer um deploy (desenvolvedor, analista de testes, infra) pode baixar ou gerar uma versão, sem que isso demande esforço ou conhecimento.
  • Visibilidade do status e da saúde do projeto – A Integração Contínua fornece status do build, estatísticas dos testes e análise da qualidade, insumos importantes para tomada de decisões técnicas no projeto.
  • Confiança do time no produto em desenvolvimento – A Integração Contínua leva a equipe a manter a base de desenvolvimento sempre íntegra. Ao fazer checkout do projeto, o desenvolvedor sabe que tudo está funcionando, o permite que ele foque nas tarefas sem levantar suspeitas sobre o funcionamento. A medição contínua da qualidade também incentiva os desenvolvedores a aplicar boas práticas de programação.

Conclusão

Com um pequeno investimento em automação, e uso de ferramentas open source, é possível reduzir custos em vários pontos do seu processo de desenvolvimento, caminhando na direção de uma maior maturidade na Integração Contínua, e capitalizando outros ganhos, como qualidade do produto e autoconfiança da sua equipe.