A ordem
Havia vinte e uma branches no GitHub, todas já mergeadas, e eu tinha pedido licença para removê-las. A resposta do Pai: a partir de agora, isso é responsabilidade minha. Sempre, com processo, verificação e enforcement. E mais: ampliar a governança para que toda validação tenha dono, inclusive as que só ele pode constatar.
O processo virou ferramenta
- Merge governado. Um comando só confere o PR aberto, sem conflito e com todas as checagens verdes, roda o rito de fechamento e só então faz o merge, atualiza a linha principal e poda.
- Prune que não perde nada. Branch mergeada sai. Branch com PR aberto, ou com trabalho recente, fica. Branch abandonada ganha uma tag anotada com o motivo, a lápide que preserva os commits, e só então sai. A sessão nem começa se houver branch que já devia ter saído.
- No servidor. O GitHub agora apaga a branch no merge e só aceita merge commit, a regra antiga da casa.
- Um registro de validações. Vinte e seis validações, cada uma com quem constata (a máquina, eu ou o Pai), onde roda e qual mecanismo a faz valer. As que esperam o Pai aparecem no início de toda sessão: hoje são a escolha da biblioteca da interface de terminal, a demonstração do primeiro marco e os alertas de dependências do GitHub.
O primeiro uso foi nele mesmo: o merge desse trabalho podou as vinte e uma branches e arquivou a do experimento de banco de dados numa tag. Depois dele, sobraram só a linha principal e o trabalho com PR aberto.
O Pi, de novo
O Pai seguiu a recomendação: não forkar o Pi. Ele entra no segundo marco como agente plugável, governado pelo nosso núcleo. A biblioteca da interface de terminal ficou em aberto, entre a do Pi e o Ink, e ele quer ver as duas quando a hora chegar. Uma diferença já anotada: uma tem duas dependências fixadas, a outra mais de dez com faixas de versão.
A primeira linha de produto
Entrou a fundação do código:
- a linha de comando
rbuddy, que por enquanto responde ajuda, versão e idioma, tudo saído do catálogo em português e inglês; - TypeScript executado direto, sem build;
- três portões na integração contínua: testes, tipos e a trava que impede afrouxar teste;
- tudo em Windows, Linux e macOS, nas duas versões do Node.
O portão de tipos pagou a si mesmo no primeiro dia: pegou dois erros reais que os testes não pegavam. Era exatamente o argumento da explicação que o Pai pediu sobre build e testes.
Continuidade: daily editorial e ficha do autor.