CI que te diz a verdade

O propósito da integração contínua é responder uma pergunta com rapidez e honestidade: essa mudança é segura para merge? A maioria das pipelines que reviso responde devagar e com desonestidade. Levam vinte minutos, ficam verdes com o código quebrado, ficam vermelhas sem nada errado, e o time aprendeu a clicar em 'rerun' até aparecer a cor que quer. Nesse ponto a pipeline é ritual, não sinal.

Os três jeitos que o CI mente

A primeira mentira é o teste instável. Um teste que falha uma vez a cada vinte, por motivos sem relação com a mudança, ensina o time que vermelho não significa nada. Cada teste instável reduz a confiança em cada falha real. A resposta certa não é retentar automaticamente. É colocar em quarentena no mesmo dia, corrigir ou apagar dentro da semana, e tratar a taxa de instabilidade como métrica que precisa ficar em zero.

A segunda mentira é o build verde em código quebrado. Isso acontece quando os testes não exercitam o que mudou: a migration que nunca roda no CI, a variável de ambiente que está definida na pipeline mas falta em produção, o passo de build que passa porque usa o cache da saída anterior. A pipeline confirma que o código de ontem ainda funciona. A solução é fazer o CI construir o artefato exato que vai ser publicado, de um checkout limpo, e rodar as migrations contra um engine de banco real, não um mock.

A terceira mentira é o build vermelho que não é sobre o código. O download de uma dependência estourou o tempo. Um runner ficou sem disco. Uma API de terceiro usada num teste de integração estava fora. São falhas de infraestrutura vestidas de falha de teste, e precisam ser separadas: status distinto, alerta distinto e nunca motivo para um dev olhar o próprio diff.

Como é uma pipeline verdadeira

Ela roda em todo push, e as checagens rápidas terminam em menos de cinco minutos. Type check, lint, testes unitários, um build de produção. Qualquer coisa mais lenta roda num segundo estágio que não impede o dev de continuar, mas impede o merge.

Ela constrói o artefato publicável uma vez e reutiliza em todos os passos seguintes. A imagem ou o bundle que passou nos testes é o que vai para produção. Se o passo de deploy reconstrói, os testes eram sobre outra coisa.

Ela roda contra dependências reais onde o risco é real. Um container de banco descartável para migrations e testes de integração. A fila de verdade. O cache de verdade. Mock é para terceiro que você não controla, e mesmo assim, um teste de contrato contra uma resposta gravada é melhor do que um stub escrito à mão que vai se distanciando.

Ela reporta num formato em que um humano consegue agir. Não uma parede de log, mas o nome do teste que falhou, a asserção e um link para a linha. A diferença entre uma pipeline que é lida e uma que é rerodada é se a falha é legível em dez segundos.

As regras que eu imponho

• Teste que ficou instável vai para quarentena no dia em que ficou, e a lista de quarentena é revisada toda semana.
• A branch principal está sempre publicável; main vermelha é incidente, corrigido ou revertido dentro da hora.
• Sem merge sem verde, sem exceção, inclusive para quem é dono do repositório.
• Falhas de infraestrutura no CI são reportadas separadas das falhas de teste e nunca exigem mudança de código para resolver.
• A duração da pipeline é acompanhada, e qualquer coisa acima de dez minutos no estágio bloqueante vira tarefa de engenharia.

Por que importa mais do que parece

Uma pipeline que diz a verdade muda como o time se comporta. Deploy fica entediante porque verde significa seguro. Revert fica rápido porque vermelho significa quebrado. Revisão fica mais curta porque quem revisa confia na máquina para checar o mecânico e gasta a atenção em design. O custo de uma pipeline verdadeira é alguns dias de setup e uma hora semanal de manutenção. O custo de uma que mente é pago em cada merge, por cada engenheiro, para sempre, na forma de 'deixa eu só rerodar'.