MÓDULO 3.3

🚦 Quality Gates

Quality Gates são condições obrigatórias antes de uma mudança avançar. O princípio é curto: uma regra escrita em texto é útil; a mesma regra transformada em teste automático é muito mais confiável.

6
Tópicos
50
Minutos
Core
Nível
Prático
Tipo
0%0 de 6
1

🚦 Transforme regra escrita em verificação

Toda equipe tem regras combinadas: "não commitar segredo", "manter compatibilidade", "cobrir com teste". Elas funcionam enquanto todo mundo lembra. Com IA gerando volume, lembrar deixa de ser suficiente — a regra precisa executar sozinha.

build lint testes cobertura estática segurança revisão aprovação → deploy falhou em qualquer caixa? o código não avança — não existe "só desta vez"

Como ler: é uma fila, não um menu. Cada caixa é uma condição obrigatória; a última (aprovação humana) só recebe o que já passou por tudo. O valor do desenho está na frase de baixo: um gate que pode ser pulado deixou de ser gate.

🆕 Novo aqui?

Quality gate é uma checagem automática que impede a mudança de avançar quando falha. Análise estática examina o código sem executá-lo, procurando padrões perigosos. Teste de contrato verifica que a interface que outros sistemas consomem continua se comportando como antes.

Obrigatório

Não é recomendação

Automático

Não depende de lembrar

Objetivo

Passa ou não passa

Igual para todos

Humano e agente

2

🏗️ Monte a base: build, lint e testes

Estes três são os gates que o próprio agente usa dentro do loop. Por isso a característica mais importante deles não é rigor — é velocidade e determinismo.

✓ Gate que serve ao loop

  • Roda em segundos, não em dezenas de minutos
  • Mesma entrada, mesmo resultado — sempre
  • Mensagem de erro que diz onde e por quê
  • Um comando único, documentado no AGENTS.md

✗ Gate que atrapalha

  • Suíte de 40 minutos — o loop não pode usá-la
  • Teste instável que falha uma vez a cada cinco
  • Erro genérico ("failed") sem contexto
  • Sequência de sete comandos que só o veterano sabe

💡 Dica prática

Divida a suíte: um alvo rápido para o loop (unitários dos módulos afetados, poucos segundos) e um alvo completo para o merge. Sem essa separação, ou o loop fica lento demais para servir, ou você corta verificação onde não devia.

Rápido

Loop depende disso

Determinístico

Instável mata confiança

Dois alvos

Loop e merge

Lint

Encerra debate de estilo

3

📜 Adicione testes de contrato e cobertura mínima

Quando o volume de mudanças cresce, o contrato é a primeira vítima silenciosa — e quem descobre a quebra é quem consome sua API. Um teste de contrato transforma esse acordo tácito em gate.

🧪 Exercício copiável — gerar os gates que faltam

Objetivo: descobrir quais regras do seu time ainda são "combinado" e não gate. Rode no repositório real.

Leia a configuração de CI em <caminho do workflow/pipeline> e o AGENTS.md.

1. liste os gates que JÁ existem hoje (o que bloqueia o merge de verdade);
2. liste as regras que estão escritas em texto mas NÃO são verificadas
   automaticamente (ex.: "não commitar segredo", "manter compatibilidade");
3. para cada regra do item 2, proponha a verificação automática
   correspondente e diga o custo (baixo/médio/alto) de implementá-la;
4. ordene por (impacto se violada) ÷ (custo de implementar);
5. implemente APENAS a primeira da lista e me mostre o diff.

Não altere gates existentes. Não desative nada.

Como verificar: abra um PR de teste que viola de propósito a regra recém-automatizada (por exemplo, um arquivo com um segredo falso). Se o pipeline não ficar vermelho, o gate não existe — existe só a configuração dele.

📐 Sobre cobertura

Cobertura mínima serve como piso que impede queda, não como meta a perseguir. Um agente que precisa "bater 90%" gera testes que executam o código sem afirmar nada. Prefira: não pode cair em relação à base, e o código novo precisa vir coberto.

Contrato

Acordo virou teste

Piso

Cobertura não cai

Código novo

Chega coberto

Meta de %

Gera teste vazio

4

🛡️ Inclua análise estática e segurança

São achados objetivos e caros — o perfil perfeito para bloqueio automático. Nenhuma dessas verificações deveria depender de um revisor atento numa sexta-feira à tarde.

1

Segredo no repositório — bloqueio absoluto

Chave, token ou senha comitada é incidente, não achado. E lembre: apagar no commit seguinte não resolve — o segredo já está no histórico e precisa ser rotacionado.

2

Vulnerabilidade crítica em dependência

Bloqueia o merge quando é crítica e explorável no seu contexto. Calibre a severidade — scanner barulhento demais acaba sendo desligado por todo mundo.

3

Padrões perigosos e regras de arquitetura

Concatenação de SQL, desserialização insegura, import atravessando fronteira de domínio. Aqui a análise estática vira o gate arquitetural do módulo 3.2.

Segredo

Bloqueio + rotação

CVE crítica

Barra o merge

Calibrar

Barulho vira desligamento

Fronteira

Vira regra estática

5

⚡ Controle desempenho e reversibilidade

Degradação de desempenho entra devagar, uma mudança pequena de cada vez, até virar incidente. E migração irreversível é o item que transforma um erro de dez minutos em uma noite inteira.

📊 Gates que valem a pena

  • Orçamento de desempenho: tempo de resposta e consultas por requisição não podem piorar além de X% da base.
  • Migração reversível: toda migração vem com o caminho de volta — e ele é executado no ambiente de teste.
  • Compatibilidade: nenhuma quebra de contrato público sem versionamento e aviso.
  • Tamanho da mudança: diffs acima do limite acordado exigem justificativa explícita.

⚠️ Atenção

Rollback que nunca foi executado não é rollback — é intenção. Se a sua migração tem um script de volta que ninguém rodou, considere que ele não existe.

Orçamento

Desempenho tem teto

Reversível

E testado

Compatível

Ou versionado

Tamanho

Diff também é gate

6

✅ Defina o critério para liberar a mudança

O código só avança quando todos os gates obrigatórios são atendidos. Gate que pode ser pulado "só desta vez" não é gate — é sugestão. E a exceção vira regra em duas semanas.

Checklist de liberação

☐ build concluído · ☐ lint aprovado

☐ testes unitários, de integração e de contrato aprovados

☐ cobertura mínima alcançada (não caiu)

☐ nenhuma vulnerabilidade crítica · ☐ nenhum segredo exposto

☐ contratos preservados · ☐ migrações reversíveis

☐ desempenho dentro do limite

☐ revisão concluída (agente + humano)

☐ aprovação humana registrada quando a ação é irreversível

Checagem rápida: a entrega é hoje e o gate de cobertura falhou por 0,4%. O que fazer?

Todos

Sem exceção silenciosa

Exceção

Registrada, com prazo

Evidência

Anexada à liberação

Protege

O gate é do time

📌 Resumo do Módulo

Regra em texto vira teste - é o princípio central dos gates.
Base rápida e determinística - build, lint e testes servem ao loop do agente.
Contrato e cobertura - piso que não pode cair; código novo chega coberto.
Segurança é bloqueio - segredo e CVE crítica não passam.
Desempenho e rollback - orçamento explícito e volta testada.
Obrigatório é obrigatório - exceção só registrada, com dono e prazo.

Próxima trilha:

Trilha 4 - Arquitetura na era da IA: legado, repositórios legíveis por agentes e controle de dívida.