O modo de falha da entrega contínua não é um pipeline avariado. É um pipeline que as pessoas contornam: integrar com a build vermelha porque aquele teste é instável, implantar manualmente porque o pipeline demora quarenta minutos. Assim que contornar se torna rotina, as barreiras de qualidade passam a ser decorativas.
Rápido o suficiente para manter a atenção
O nosso objectivo é menos de dez minutos do push a um ambiente de pré-visualização implantado. Acima disso, os programadores mudam de contexto e deixam de acompanhar. Chegar lá exige trabalhos em paralelo, cache agressiva de dependências e correr apenas os testes afectados pela alteração nos pull requests, deixando a suíte completa para o ramo principal.
Eliminar testes instáveis ou corrigi-los na mesma semana
Um teste que falha intermitentemente ensina a equipa a ignorar builds vermelhas, o que é muito mais nocivo do que a cobertura que fornece. Coloque-o em quarentena imediatamente, corrija-o dentro da semana, ou remova-o. Não há terceira opção aceitável.
Impor também requisitos não funcionais
Se o desempenho e a acessibilidade importam, imponha-os onde não podem ser ignorados. Orçamentos de tamanho de bundle, limiares de Lighthouse e verificações automáticas de acessibilidade pertencem ao pipeline — uma regressão deve fazer falhar a build em vez de ser descoberta por um utilizador.
- name: Impor orcamentos
run: |
npm run build
npx lighthouse-ci autorun --assert.preset=lighthouse:recommended
npx size-limitPor fim, torne a reversão banal. Se reverter um lançamento exige uma reunião de decisão, as equipas implantam menos vezes e cada lançamento carrega mais risco. Um comando, ensaiado, muda toda a postura.