Existe um momento traiçoeiro em todo projeto de software: aquele em que alguém diz “está pronto” e ainda não está no ar. Entre um e outro cabem uma revisão esquecida, uma variável que ninguém configurou e uma publicação feita à mão numa sexta-feira à noite.
A esteira existe para que esse intervalo não dependa de ninguém lembrar de nada.
O ponto de partida
Vamos acompanhar uma mudança fictícia, mas bem típica: o cliente quer que o formulário de contato aceite telefone com DDI. A issue diz o que precisa ser verdade no fim — o campo aceita números de outros países e continua recusando o que não é telefone.
Um agente pega a issue, trabalha numa cópia isolada do repositório e entrega um merge request para a branch de integração. Até aqui, nada foi publicado. E nada será, sem passar pelo resto.
Os portões, em ordem
Todo merge request atravessa a mesma sequência. A configuração é parecida com esta:
stages: [verificar, revisar, publicar, conferir]
tipos-e-testes:
stage: verificar
script:
- bun install --frozen-lockfile
- bun run check
- bun test
segredos:
stage: verificar
script:
- gitleaks detect --no-banner
publicar:
stage: publicar
rules:
- if: $CI_COMMIT_BRANCH == "staging"
script:
- ./deploy.sh
conferir:
stage: conferir
script:
- ./smoke.shCada etapa tem um papel diferente, e nenhuma substitui a outra:
| Etapa | O que ela garante |
|---|---|
| Verificar | o código compila, os testes passam e nenhum segredo vazou |
| Revisar | alguém que não escreveu o código confirma que ele entrega o pedido |
| Publicar | a versão aprovada vai ao ar sem intervenção manual |
| Conferir | o que está no ar é, de fato, a versão nova — e responde |
A revisão não é do mesmo agente
O agente que escreveu o código não aprova o próprio trabalho. A revisão é feita por outro agente, com outras instruções, cujo único objetivo é encontrar o que não está certo: critério de aceite pela metade, comportamento quebrado, falha de segurança.
Se a revisão reprova, o trabalho volta com o motivo escrito. Se aprova, o merge acontece — e só então a publicação começa.
Publicado não é o mesmo que no ar
Esse é o detalhe que a maioria das esteiras ignora. O comando de publicação terminar sem erro não prova nada. Pode ter subido a versão antiga de novo. Pode ter subido a nova e ela não estar respondendo.
Por isso a última etapa confere o efeito: o serviço que está rodando foi de fato substituído, e a versão nova responde como deveria. Se não, a esteira fica vermelha e a gente fica sabendo antes do cliente.
Pipeline verde não prova efeito. O efeito se prova olhando para o efeito.
Em quanto tempo?
Numa mudança pequena como a do telefone, a esteira inteira leva poucos minutos. O número exato importa menos do que o fato de ser sempre o mesmo caminho: a mudança de uma linha e a de mil linhas atravessam os mesmos portões.
É isso que permite entregar muitas vezes por dia sem que nenhuma delas seja um salto no escuro.