tderoussel/portão-de-embarque

Portão de embarque

Cada regra aqui existe porque a verificação óbvia uma vez retornou um falso positivo. Execute o portão antes da afirmação, não depois.

Adapte os detalhes à sua stack; a forma — o que tornaria essa afirmação falsa? — é a parte transferível.

A regra da afirmação

Uma afirmação sobre produção exige uma consulta à produção.

Um teste que passa não é produção. Um PR mesclado não é produção. Um deploy verde não é produção. Cada um desses é uma afirmação sobre um sistema diferente daquele sobre o qual você está afirmando.

Se nenhum humano examinou o resultado, não está "verificado" — diga o que você realmente verificou.

Verificação de deploy

• Saiba o que realmente dispara um deploy. Em um host integrado com git, é o push, não uma invocação de CLI. Implantar via CLI quando o projeto implanta por push produz uma build que não é a que os usuários recebem.
• Verifique a conta que possui o projeto. Uma CLI logada localmente pode estar autenticada como uma conta pessoal que não possui o projeto de produção — cada comando então é bem-sucedido contra o alvo errado, silenciosamente.
• Verifique com status do commit contra o SHA implantado, não um olhar de painel.
• Confirme o deployment que é produção atual, não apenas um que está PRONTO. Vários podem estar prontos ao mesmo tempo.
• Funções edge/serverless são implantadas separadamente do aplicativo. Um PR mesclado não implanta uma função edge; verifique sua versão explicitamente.
• Mudanças apenas no cliente podem não precisar de deploy de função — não espere por uma que nunca virá.
• Reobtenha o manifesto ativo antes de afirmar uma versão. Trabalho paralelo incrementa versões por baixo de você.

Verificação de CI

• Portão em cada contexto necessário, não no primeiro verde.
• Nunca faça portão em um comando com pipe. algum-check | tail reporta o código de saída de tail, mascarando a falha real. Em shells sem PIPESTATUS (zsh difere de bash aqui), é fácil errar — verifique o status do próprio comando.
• steps: 0 significa que o job nunca foi executado, não que passou. Uma API de checks pode reportar uma conclusão para um job que não fez trabalho algum.
• Uma falha suspeitamente rápida sem steps geralmente é um problema de cobrança ou permissões, não um problema de YAML.
• Reexecutar apenas jobs com falha reproduz um snapshot desatualizado da branch. Atualize a branch primeiro, depois reexecute.
• Uma lista de checks omite jobs que nunca foram criados. Ausência de falha não é evidência de aprovação.
• gh pr create requer um --base explícito. Heredocs encadeados ao redor dele podem falhar silenciosamente.

Portões de tipo e lint

• Projetos TypeScript grandes podem precisar de um heap Node aumentado; sem ele tsc morre de uma forma que parece um erro de código.
• Saiba quais diretórios seu typechecker e linter realmente cobrem. Diretórios de funções edge são frequentemente excluídos de ambos. Se eles executam em um runtime diferente, verifique-os com o próprio verificador desse runtime — um job de teste não é um portão de tipo.
• Construa em worktrees ou checkouts limpos, não em um diretório de trabalho com deriva não commitada.

Banco de dados

• Nunca envie schema ou execute migrações casualmente contra produção. Aplique schema através do caminho revisado que o projeto escolheu, uma vez.
• Chame novos procedimentos armazenados contra o banco de dados real antes de acreditar neles. Mocks escondem erros de runtime que só aparecem com tipos reais e ambiguidade real.
• Se o conjunto de testes faz mock do banco de dados globalmente, um teste unitário que passa não prova nada sobre o banco de dados.
• Nunca faça compare-and-set em uma coluna gerenciada por trigger — o trigger a altera por baixo da escrita.
• Meça o raio de explosão de uma mudança contra dados de produção antes de mesclar. Um filtro que parece estreito contra um seed local pode corresponder a uma parcela muito diferente de linhas reais.

Armadilhas de ambiente

• Nunca assuma o fuso horário da máquina — execute date. Testes dependentes de data falham no deslocamento, e a falha parece um bug de código.
• Uma identidade git não definida pode bloquear deploys e se manifestar como um erro de rede não relacionado.
• Defina variáveis de ambiente do host a partir de um arquivo, não por atribuição inline; shells e CLIs podem incorporar quebras de linha finais que corrompem o valor invisivelmente.
• Sucesso de job agendado não é sucesso de efeito do job: um runner reportando succeeded significa que a invocação retornou, não que o trabalho aconteceu. Verifique o efeito.

Saída

Estados cada portão como PASSOU (evidência) ou NÃO VERIFICADO (porquê).

Nunca implique que um portão foi executado quando não foi. Se algum portão falhar ou não for verificado, diga claramente que a mudança não está verificada — reter a afirmação é correto.