GitHub 2011–2020: o Hubot transforma o chat em console de deploy

Em 2011, a pequena equipe do GitHub administrava a infraestrutura pelo chat do Campfire, e o bot deles tinha crescido 'maior e mais bagunçado'. Eles o reescreveram do zero e o abriram como código aberto sob o nome Hubot — um bot que envia código, fica à frente do servidor de CI e torna os comandos de operações visíveis para toda a empresa.

Colocar as ferramentas na sala de chat: um bot que faz deploy de código, executa CI e avisa o último responsável pelo deploy quando os erros disparam — cada ação visível, auditável e aberta a todos.

O Hubot escuta comandos como '/deploy my-feature'; os engenheiros fazem deploy pelo chat e, quando a taxa de exceções dispara, o bot avisa o último responsável pelo deploy com um link para o painel interno Haystack, atribuindo implicitamente a responsabilidade. Foi aberto como código aberto em 2011 e, em 2020, o GitHub ainda realizava de 120 a 150 deploys de produção por semana via ChatOps, com lançamentos canário e centenas de pull requests agrupados por deploy.

O deploy no GitHub tornou-se um comando de chat que qualquer um podia executar e todos podiam ver: o mesmo número de deploys semanais agora entrega muito mais mudanças, as reversões permaneceram baixas o suficiente para construir uma 'cultura de confiança', e o termo ChatOps se espalhou pela indústria à medida que as equipes copiavam o padrão.

Em 2011, o GitHub era uma pequena empresa operando um serviço muito grande, e sua equipe vivia no chat do Campfire. O bot deles tinha crescido 'maior e mais bagunçado', então o reescreveram do zero e o abriram como código aberto: o Hubot, 'um bot incrível para o Campfire' que os fazia rir, enviava o código deles e servia como interface para o servidor de CI.

A prática cresceu até o que o GitHub chamou de ChatOps: os engenheiros executam '/deploy my-feature' no chat, e o Hubot cuida da autenticação, dos estágios e dos lançamentos canário. Quando as exceções disparam após um deploy, o Hubot avisa o último responsável pelo deploy com um link para o Haystack, o painel interno de exceções do GitHub — 'o benefício imediato desse aviso é que ele define implicitamente um responsável'.

Em 2020, o padrão estava maduro: a equipe de deploy do GitHub descreveu implantações iniciadas com 'uma série de comandos do Hubot', realizando de 120 a 150 deploys de produção por semana para o github.com, com mais de 400 pull requests enviados em uma única semana, e confiança suficiente no processo para que as reversões permanecessem baixas e os desenvolvedores pudessem fazer merge e seguir em frente.

Eliminou o gargalo de 'quem tem permissão para mexer na produção' — qualquer engenheiro podia fazer deploy pelo chat, e a ação era visível para toda a empresa.

O bot tornou a responsabilidade implícita: o último responsável pelo deploy é avisado quando os erros disparam, então os problemas encontram um dono em vez de esperar pela triagem.

Como cada comando era executado em um canal compartilhado, o deploy tornou-se auditável e ensinável — novos engenheiros aprendiam operações observando o chat.

A abertura do código do Hubot transformou uma conveniência interna em um padrão da indústria, popularizando o termo ChatOps.

Uma ferramenta interna vence quando reduz o custo social da ação: colocar as operações no chat tornou os deploys visíveis, auditáveis e seguros de delegar — a mudança de interface é o que mudou a cultura.

O ChatOps tornou-se uma prática amplamente copiada, e o Hubot cresceu para um projeto comunitário com adaptadores para Slack, Discord e Teams. No GitHub, o pipeline de deploy continuou evoluindo — IssueOps e GitHub Actions depois se basearam na mesma ideia — enquanto o princípio subjacente, permitir que as pessoas executem infraestrutura a partir das ferramentas que já compartilham, permaneceu central na forma como o GitHub entrega software.