Como é um bom pipeline de CI para um serviço backend?

Ele roda em cada push, devolve feedback em menos de dez minutos, e bloqueia o merge na falha. Ordene os estágios do mais barato ao mais caro: lint e checagem de tipos, testes unitários, depois testes de integração contra dependências reais em containers, depois um artefato de build que você promove em vez de reconstruir por ambiente. Mantenha determinístico, coloque testes instáveis em quarentena em vez de repetir às cegas, e deixe as mesmas checagens rodáveis localmente.

A primeira propriedade é velocidade, porque um pipeline que leva quarenta minutos é um que as pessoas contornam. Eu quero lint e checagem de tipos falhando em menos de um minuto, testes unitários em poucos, e o conjunto inteiro em menos de dez. Então os estágios vão do mais barato primeiro: checagens estáticas, testes unitários, depois testes de integração contra Postgres e Redis reais em containers em vez de mocks, porque os bugs com que eu me importo vivem na fronteira. Depois ele constrói um artefato, uma imagem de container marcada com o sha do commit, e todo ambiente depois disso faz deploy daquela imagem exata. Reconstruir por ambiente significa que a coisa que você testou não é a coisa que você entregou. Sobre testes instáveis eu sou rígido: um retry automático é um jeito de esconder uma corrida real, então um teste instável vai para a quarentena e alguém assume corrigir ele naquela semana. E eu quero os mesmos comandos rodáveis localmente, geralmente atrás de um makefile, porque depurar empurrando commits para ver o que o CI diz é um jeito miserável de passar a tarde.