Bot Discord Multi-Time para Deploy com Guardrails Human-in-the-Loop
Perfil:Operação interna multi-time em várias regiões
Cinco times regionais compartilhando uma plataforma, cada um com cadência de deploy, ambiente e usuário SSH próprios. Construí um bot Discord que deixa cada time fazer deploy do chat sem encostar na infra do outro time — e que recusa qualquer operação destrutiva sem confirmação humana.
Resultados
O problema
Cinco times regionais (pense: escritórios de marca em países diferentes) compartilhavam uma única plataforma de deploy mas tinham que ficar estritamente isolados entre si. O setup anterior era um usuário SSH `deploy` compartilhado em todo servidor e uma página de wiki com comandos. Previsivelmente: vez ou outra alguém deployava a mudança do Time A no ambiente do Time B, e rsync quebrava silenciosamente semântica de ownership de arquivos que dependiam disso.
A pergunta interessante: cada time pode fazer deploy do próprio canal Discord, sem nunca conseguir tocar na infra de outro time, e com operações destrutivas exigindo confirmação humana explícita?
A abordagem
Uma instância única do bot, isolamento por time enforçado em cada camada.
Usuário SSH por time — `SSH_DEV_DEPLOY_USER={team}`, nunca o `deploy` compartilhado. rsync com owner-awareness para de corromper permissões. A SSH key de cada time é provisionada uma vez via um bot setup-secrets construído sobre um GitHub App.
Comandos escopados por canal — o bot só aceita comandos de deploy do canal dedicado a cada time. Canal errado = nenhum comando. O mapeamento canal → time é enforçado no server, não no cliente.
Conjunto de comandos em allowlist — `deploy`, `rollback`, `logs`, `status`, `password`, `restart`. Qualquer coisa fora da lista é ignorada silenciosamente. Sem shell escape.
Human-in-the-loop em ops destrutivas — `rollback`, `restart` e qualquer comando que toque infra compartilhada exige resposta `confirm` em 30 segundos. A confirmação é logada com o user ID Discord do requisitante.
Operações longas via SSH `nohup` — deploys que levam minutos rodam server-side sob `nohup` com o ID do canal Discord como parte do nome do lockfile. O bot consegue retomar reporting de status se ele mesmo reiniciar no meio do deploy.
Disciplina em credenciais — `htpasswd` e outras mudanças ad-hoc de credencial passam pelo flow `password` do bot. `htpasswd` manual é motivo para revogar acesso SSH.
Audit log em canal — todo comando, sucesso ou falha, é resumido em canal de auditoria dedicado. Times veem o próprio; o time de plataforma vê todos.
O resultado
Cinco times deployando autonomamente dos próprios canais. Zero acidentes cross-team desde o rollout. Audit log responde "quem deployou o quê quando" em segundos. O bot setup-secrets eliminou a cerimônia manual de `ssh-copy-id` para servidores novos.
Por que isso importa
A maioria das ferramentas de "deploy from chat" assume um único time e um único ambiente. A engenharia interessante para plataformas multi-time é tornar isolamento impossível de bypassar mesmo por acidente: usuários SSH por time, comandos escopados por canal, comandos em allowlist, confirmações obrigatórias em ops destrutivas. A superfície de chat é só glacê em cima de um pipeline de deploy que já enforça os invariantes certos.
Um engajamento parecido para o seu time?
Todo engajamento da Tyber.io começa pela mesma pergunta: qual problema dói mais e qual é o mais resolvível. Fale direto com o technical lead — sem funil de SDR, sem repasse pra júnior.
Falar com o technical lead