Como minha equipe fez 100 deploys pra produção numa sexta feira
Oi, eu sou o Chris 👋
Já postei algumas vezes aqui sobre os SaaS que venho construindo, e prometo que dessa vez não tem jabá (só um pouco de bastidor técnico que achei que valia compartilhar).
Geralmente deixo esse tipo de conteúdo pro dev.to, mas esse assunto rendeu mais do que eu esperava, então resolvi trazer aqui também.
💥 O Tweet
Na última sexta, eu publiquei esse tweet:
Sim, é verdade, nós fizemos 100 deploys na sexta. E sim, é muita coisa.
Isso foi na AbacatePay 🥑, onde construímos tudo em público e fazemos tudo com entrega contínua. Como vejo poucos relatos brasileiros sobre CD em larga escala, achei que seria legal explicar como fazemos isso acontecer.
👨👩👧👦 Como o time funciona
Nosso time tem 9 devs (11 contando os sócios).
Todos sabem no que cada um está trabalhando.
A comunicação rola tanto de forma síncrona quanto assíncrona, e temos um processo sólido de RFCs (Request for Comments), onde debatemos e alinhamos as ideias antes de codar.
Cada dev conhece pelo menos uma feature de ponta a ponta, mas todos contribuem em tudo que se sentirem confortáveis — mesmo que não dominem 100%.
🔄 O processo
Nosso fluxo de trabalho gira em torno de integração e entrega contínua, e um bom exemplo disso é nosso SDK em Node.js:
- Cada PR é aberto por quem fez a tarefa.
- O review é feito por quem cuida daquela feature.
- Quando aprovado, o código vai pra
main— sem firula de git flow. Usamos trunk-based development.
✂️ PRs pequenos, mudanças independentes
Cada PR é pequena e específica. A ideia é que cada commit faça uma única coisa.
Por exemplo, digamos que estou trabalhando no comprovante de transação. A estrutura da tarefa ficaria algo assim:
# Comprovante de transação
[documentação, links, RFC]
- incluir campo receiptUrl no model de Transaction
- salvar dados do pagador na Transaction
- criar tela de comprovante
- busca receipt pela transaction recebida na URL
- exibe recebedor e pagador
- opção de download em PDF
Cada subtask é independente. E aí você pode se perguntar:
"Mas como testar o front sem ter o backend pronto?"
"Como saber os campos que vão no comprovante?"
A resposta: RFC.
Com tudo documentado, os devs podem trabalhar em paralelo sem precisar se alinhar o tempo todo.
🚀 Um exemplo prático
Se eu começasse hoje pela task incluir campo receiptUrl, eu faria dois commits simples:
- Adiciona o campo
receiptUrlno schema do banco. - Retorna o campo na API.
O receiptUrl é só o nosso domínio + o ID da transação. Fácil.
Depois disso, abro o PR. Não preciso esperar os dados do pagador estarem prontos — já sei, via RFC, o que vai estar ali depois.
A próxima task, salvar dados do pagador, gera outro PR, com um commit por banco parceiro e uma migration pra popular dados antigos.
E assim vai.
⚙️ CI/CD na prática
Nosso processo de CI/CD verifica:
- Nome e descrição da PR
- Evidências e screenshots (quando faz sentido)
- Linter e testes passando
- Build funcionando
- Se há riscos ou regressões
PR aprovada → merge na main → deploy automático.
Se for reprovada, sempre tem um motivo claro e uma discussão saudável sobre simplicidade ou clareza.
🚧 Subir feature incompleta? Tudo bem!
Nem toda feature precisa estar 100% pronta pra ir pra produção.
A gente usa feature flags pra isso.
Se uma parte da feature ainda não está implementada, mas o código já está testado e não quebra nada, ela sobe assim mesmo — escondida atrás de uma flag.
Exemplo: no comprovante de transação, se a tela está pronta mas o download em PDF ainda não, subimos a tela com a flag RECEIPT_ENABLED: true, e o botão de download fica atrás de RECEIPT_PDF_DOWNLOAD: false.
Isso permite que:
- O time continue trabalhando em paralelo sem se bloquear.
- A gente já teste partes da feature em produção (com dados reais).
- Evite branches gigantes e conflitos desnecessários.
E claro, ao finalizar tudo, basta ativar a flag — sem precisar fazer um novo deploy.
🎯 Por que isso importa?
Nosso maior valor está em ouvir nossos clientes.
Toda startup pequena é, no fundo, uma consultoria pros seus clientes principais.
A gente faz várias entregas por dia pros nossos maiores clientes. Eles não querem algo pronto como nos concorrentes — eles querem ser ouvidos. Querem solução rápida pros próprios problemas.
E pra isso, a gente precisa iterar rápido.
Se você achou esse post útil, curte aí ou comenta — posso detalhar mais sobre nossos processos, RFCs ou até sobre como usamos feature flags. Valeu por ler até aqui! 🥑