Tema: continuous-integration
-
Como projetar um pipeline de integração contínua
Um pipeline de CI deve ser rápido, testar a si mesmo e ser idêntico para toda mudança: compilar a partir de um checkout limpo, executar linters e testes em etapas, falhar de forma visível e manter o tempo total curto o bastante para que as pessoas esperem pelo resultado.
-
Manter verificações locais e de CI idênticas: um único ponto de entrada, ferramentas fixadas e o mesmo contêiner
Uma verificação que passa localmente deve passar no CI e vice-versa: defina cada verificação uma só vez como uma tarefa nomeada, fixe a toolchain num manifesto versionado do qual o bootstrap e o pipeline instalam, execute o CI na mesma imagem de contêiner do ambiente de desenvolvimento, fixe locale e fuso horário, e trate qualquer falha exclusiva do CI como um bug de paridade a eliminar antes de corrigir o sintoma.
-
Bancos de dados efêmeros em contêineres para testes de integração
Suba o motor de banco de dados real em um contêiner descartável a cada execução de testes, mantenha os dados em memória, aplique as migrações uma só vez em um banco-modelo e copie-o para cada arquivo de teste. Assim, os testes exercitam o planejador, as constraints e o comportamento de isolamento reais, em vez de um substituto em memória.
-
Ordem de dependências com travessia de grafos: BFS, DFS e ordenação topológica
Modele dependências como um grafo dirigido, use busca em largura ou em profundidade para encontrar tudo o que uma mudança afeta e aplique o algoritmo de Kahn ou a pós-ordem do DFS para obter uma ordem de build ou de migração que reporta ciclos em vez de escondê-los; graphlib e tsort implementam a ordenação.
-
Executando testes de mutação sem se afogar em mutantes sobreviventes
Rode uma ferramenta de mutação em um único módulo, classifique cada mutante sobrevivente como asserção ausente, caso ausente ou mutante equivalente, corrija os dois primeiros, exclua o terceiro e limite o tempo de execução com execuções incrementais ou restritas ao diff; use a pontuação como um ratchet por módulo, e não como meta global.
-
Testes automatizados de jogos: combine verificações headless com evidência de renderização
Como projetar uma suíte prática de testes para jogos, com testes de lógica isolados, verificações de cena reproduzíveis e comparações controladas de capturas de tela, incluindo políticas claras para falhas e imagens de referência.
-
Quais verificações pré-implantação realmente barraram uma versão ruim no último ano, e quais nunca dispararam?
Pergunta em aberto: pipelines acumulam gates (testes, varreduras, smoke tests, análise de canary, aprovações manuais, prazos de rollout), e a documentação do Kubernetes indica que um Deployment travado apenas é reportado, sem rollback; quais gates têm histórico de barrar uma versão ruim, quais nunca dispararam e quais só dispararam em falsos positivos?
-
Testes de contrato orientados pelo consumidor: verificar integrações sem um ambiente compartilhado
Um contrato orientado pelo consumidor registra as requisições que o consumidor faz e a resposta mínima da qual ele depende; o consumidor testa contra um mock gerado a partir desse registro, e o provedor o reproduz contra o código real. Cada lado roda no seu próprio pipeline, e uma matriz de versões indica se uma release é compatível com o que já está implantado.
-
Atestações de proveniência de build: o que a proveniência SLSA registra e como é verificada
A trilha Build do SLSA classifica o grau de confiança na proveniência de um artefato, de «a proveniência existe» (L1) até uma plataforma de build reforçada (L3). A proveniência é uma atestação in-toto que indica os digests dos artefatos, o builder, o tipo de build e seus parâmetros externos, e o consumidor a confere com uma raiz de confiança e valores esperados antes de usar o artefato.
-
Ambientes de preview por branch: uma cópia implantada por pull request, removida no merge
Dê a cada pull request uma cópia em execução da aplicação, em URL própria, construída uma vez por commit, nomeada pelo número do pull request, populada com o seed local e ligada a terceiros em sandbox; publique a URL no pull request, limite a concorrência e apague a cópia e os dados no merge, no fechamento ou por inatividade.
-
Desenvolvimento baseado em trunk e branches de curta duração
Integrar o trabalho de todos numa única linha compartilhada pelo menos uma vez por dia, manter os branches de curta duração e esconder o trabalho inacabado atrás de feature flags reduz conflitos de merge e torna a integração contínua real.
-
Git hooks para verificações locais rápidas
Hooks do lado do cliente, como o pre-commit, executam formatadores e linters rápidos antes de o commit existir; poupam tempo de revisão, mas precisam ser rápidos, não podem ser a única barreira e não são versionados pelo próprio Git.
-
Diagnosticar e eliminar testes instáveis (flaky)
Um teste instável (flaky) passa e falha sem alterações no código; as causas habituais são estado compartilhado, suposições de temporização, dependência de ordem e serviços externos reais. Coloque-o em quarentena, reproduza a falha, corrija a causa e nunca se limite a repetir a execução.
Legível por máquina: JSON