Cortei a publicação de 17 minutos para 4 na minha máquina.

A espera revelou o lugar errado para otimizar

Em novembro, o GitHub Actions acumulou 2.945 minutos no mês, sendo 2.244 em um único dia. Nas 12 falhas mais recentes de um produto que ainda não apresentei aqui, 7 aconteceram no deploy e 4 em checagens de código. Eu estava esperando uma máquina remota repetir trabalho que a minha podia provar.

Antes de mudar o processo, medi as partes do build. Eu suspeitava dos idiomas, que levavam 42 s em paralelo. O gargalo real eram 1.826 imagens refeitas a cada build, em 230 s.

A diferença orientou a correção: reaproveitar trabalho quando aquilo que o determina não mudou e executar tarefas independentes em paralelo. Sem essa medição, eu poderia otimizar os idiomas e deixar o trecho mais demorado no mesmo lugar.

O gate prova e o ship publica

O comando bun gate executa a suíte em uma cópia limpa do commit. O resultado fica associado à árvore comprovada, e o pre-push chama o gate. Assim, a mesma árvore não precisa ser provada novamente.

O bun ship publica a partir de uma cópia limpa da ponta da main, com uma trava para evitar publicações concorrentes. Ele começa por staging, confere o resultado e só então avança para produção. Se uma tentativa falha, outra pode retomar sem repetir o ambiente que já está naquela revisão.

Também há recusas explícitas: uma pasta com alterações soltas não publica, um script de release chamado diretamente é recusado e uma revisão mais antiga que a publicada não passa. Essas condições mantêm a velocidade ligada a uma revisão identificável.

O GitHub continua como rede de proteção

No push, o GitHub verifica segredos, formato e lint em cerca de 1 minuto. Trabalhos que precisam rodar com o Mac desligado continuam lá, assim como aqueles que exigem outra arquitetura ou assinatura de loja. O teste de ponta a ponta roda localmente antes da publicação que pode afetá-lo.

Na medição de 4 de novembro, a publicação de staging e produção passou de 17m39s, além da fila, para 4m29s na máquina. Quando o teste de ponta a ponta precisa rodar, o processo local leva cerca de 3 minutos a mais.

O Garfim ainda falta migrar. A regra é um padrão de trabalho, e cada produto precisa ter sua implementação adequada ao próprio repositório.

A decisão aceita riscos e tem prazo de revisão

Com o Mac desligado ou quebrado, a publicação de código para, e o agendado continua. A recuperação é qualquer máquina com o checkout e as credenciais. Uma sessão de agente nessa máquina consegue publicar em produção; a proteção depende do portão e da regra de publicar quando pedido, sem uma barreira técnica para essa autorização.

O build também roda em macOS, enquanto a publicação precisa funcionar no ambiente de destino. O teste de staging e a conferência do resultado publicado ajudam a encontrar diferenças. Quando um segundo desenvolvedor entrar no repositório, vou reabrir a decisão: minha máquina deixa de ser passagem obrigatória para todo commit.

CI/CD reúne as verificações e as etapas que levam uma alteração até a publicação. Para escolher onde cada etapa roda, eu primeiro preciso saber o que ela protege e se realmente depende de uma máquina remota.

A cópia limpa é parte dessa resposta. Ela impede que um arquivo alterado apenas na pasta de trabalho entre na prova ou na publicação por acidente. Quando o resultado do gate fica ligado à árvore conferida, posso identificar exatamente o que passou pelas verificações.

O staging também tem uma função específica: receber a revisão antes de produção para que eu confira o resultado no ambiente publicado. Retomar a partir do ambiente que já recebeu aquela revisão evita repetir trabalho sem perder a identificação do que está no ar.

Para aplicar essa ideia em outro projeto, eu começaria anotando o tempo de cada parte, a fila e o destino das falhas recentes. Depois separaria as verificações que a máquina local consegue executar das tarefas que precisam do GitHub ligado quando o computador estiver desligado. A comparação precisa acompanhar a publicação inteira, não só o comando de build.

A regra de revisão com outro desenvolvedor também faz parte do desenho. Uma solução adequada para uma pessoa pode concentrar demais o processo quando há mais gente trabalhando. Registrar essa condição agora evita confundir a decisão atual com uma regra permanente.

A economia de espera veio de medir o caminho inteiro e assumir com clareza o que mudou. A conferência depois da publicação também fez parte da migração do meu site.