Erros comuns na Integração Contínua

Alguns exemplos de erros que devemos evitar se buscamos uma Integração Contínua eficiente

Você já se perguntou o motivo da Integração Contínua, apesar de possuir todas as ferramentas e infra necessárias, não estar agregando valor esperado ao seu projeto? Talvez o problema esteja em outras etapas do ciclo de vida do software, ou até mesmo nos processos e na cultura da equipe na forma de trabalhar.

Para começar, precisamos entender o principal objetivo dessa prática de desenvolvimento de software para assim sabermos o que podemos esperar dela.

O objetivo da Integração Contínua é diminuir o tempo entre o desenvolvimento e a liberação de uma atualização do software funcionando em produção, proporcionando feedback rápido caso o pacote possa causar qualquer tipo de problema para a aplicação.

Neste post explicarei algumas técnicas, processos e também alguns erros comuns que devem ser evitados para alcançar melhores resultados com a Integração Contínua.

Feedback não confiável

Uma das vantagens da Integração Contínua é possuir várias pipelines que devolvem feedbacks rápidos para economizar tempo e possibilitar ao responsável a tomar as devidas providências o quanto antes.

Não há benefícios em possuir uma estrutura completa da Integração Contínua se os feedbacks não são confiáveis.

Por exemplo: a pipeline de testes automatizados quebra, mas é ignorada pois não é confiável o suficiente para identificar o motivo da quebra apenas pelo feedback. O motivo pode ser apenas instabilidade do ambiente, a massa utilizada, ou também o próprio código da aplicação que está com erro.

Outro exemplo seria no momento da build, onde temos um feedback informando aonde está o erro, mas a equipe responsável não tem a cultura de corrigi-lo de imediato, deixando a correção para um momento posterior, junto com muitos outros erros.

Não há sentido possuir um feedback rápido se ele não é confiável ou se nenhuma ação é tomada de imediato.

Feedback lento

Apenas utilizar uma boa ferramenta de Integração Contínua não garante que teremos feedbacks rápidos e confiáveis. É necessário também aplicar boas práticas do seu conceito.

Imagine trabalhar sem uma estrutura organizada, sem pipelines para realizar os testes automatizados, sem paralelismo e recebermos o feedback de erro apenas após o término da execução de toda a bateria de testes. Será que era realmente necessário aguardar todo esse processo para receber o feedback? Claro que não!

Para piorar a situação, e se essa bateria de testes possuísse mais testes de UI do que unitários? Além de não ser recomendado, poderia aumentar drasticamente o tempo de execução e espera pelo feedback.

Técnicas como Pirâmide de Automação de Teste (possuir mais testes Unitários do que de Serviços, e esses mais do que de UI), Smoke Test (realizar execução das principais funcionalidades de forma separada, antes da bateria de testes de regressão), e utilizar recursos como paralelismo nas execuções são exemplos que auxiliam a receber um feedback rápido. Pois se descobrimos um problema logo no começo, podemos parar os testes e focar na correção o quanto antes, e assim economizando algo muito valioso em qualquer projeto: tempo.

Acúmulo de código local pendente de integração

Uma cultura que não combina com Integração Contínua é a da equipe que não realiza a integração do seu código com o repositório pelo menos uma vez ao dia. Pois ao realizar a integração de grandes códigos ou de branchs antigas, aumenta as chances de gerar conflito com o código principal, aumentando também o tempo, complexidade e custo para correção.

Uma das vantagens da Integração Contínua é permitir que os desenvolvedores façam refactoring e integrem seu código com rapidez, pois cada integração é analisada por uma build automatizado que verifica se o novo pacote não irá gerar nenhum conflito ou quebra de código, podendo ser através de análise estática de código ou testes (desde unitários até de UI). E o pacote da atualização sendo pequeno e recente, facilita na busca da fonte da falha da integração do código, caso ocorra.

Com isso, é muito incentivado a cultura de todos da equipe em realizar sempre a integração do código no mínimo uma vez ao dia, evitando trabalhar com branchs de longa vida.

Ambientes específicos

Rodar os testes automatizados em um ambiente que é compartilhado com outras equipes como de testes manuais ou de desenvolvimento é muito arriscado, pois alterações no ambiente para outros fins pode ocasionar resultados de testes falso negativos (ex: o teste falha por causa do script de automação, e não por causa da aplicação testada), fazendo o time perder a confiança nos feedbacks, ou até mesmo falso positivos (ex: o teste passa, porém há um bug que não foi encontrado pois foi camuflado por uma alteração no ambiente), o que significa que os testes não estão sendo eficientes para encontrar bugs reais.

Integração Contínua é ideal para todos os momentos?

Apesar de inúmeros benefícios oferecido por essa pratica de desenvolvimento, com base no que foi escrito até agora, alguns requisitos mínimos são recomendados para sua implementação:

• Aplicação de testes automatizados em todas as camadas da aplicação

* Sem testes automatizados a Integração Contínua não será capaz de verificar se o novo pacote pode prejudicar a aplicação quando implantada.

• Utilização de versionamento de código

* Para realizar a integração do código é necessário possuir um versionador, que também poderá ser o gatilho das pipelines de teste

• Objetivo de descobrir problemas (erros, bug, falhas…) o mais cedo possível para serem tratadas de imediato

* Não adianta implantar Integração Contínua se a equipe não possui mentalidade ágil para resolver os problemas e analisar os feedback

• Objetivo de realizar entrega / e ou deploy contínuo

* A entrega ou deploy contínuo acaba virando consequência de uma Integração Contínua eficiente, tornando assim quase todo o processo automático

• Objetivo de obter infra-estrutura para criação de ambientes de forma automática

* A criação de ambientes também deve ser automático, pois assim é possível garantir que os testes serão executados em um ambiente exclusivo e não haverá nenhum fator desconhecido que possa influenciar no seu resultado. Tornando assim mais confiável

…e pensando além da Integração Contínua

Após a Integração Contínua, como dito anteriormente, também é uma boa sugestão pensar em implantar o Continuous Delivery (procedimento automatizado iniciado manualmente para implementar uma nova versão em determinado ambiente) ou até mesmo o Continuous Deployment (parecido com o Delivery, porém o processo é iniciado automaticamente após o Continuous Integration).

Todas essas dicas e erros que devem ser evitados são para melhorar a eficiência da Integração Contínua, pois além da ferramenta, a equipe deve conhecer e trabalhar em cima do conceito de sua prática.