Automatizando processos com Jenkins e Slack
Ninguém ai gosta de perder uma quantidade considerável de tempo fazendo uma tarefa chata né? Pior ainda quando essa tarefa é recorrente…
Nesse artigo, pretendo mostrar um pouco do que fizemos para facilitar um pouco a vida do time com Jenkins, Slack e um chatbot.
De onde surgiu a necessidade
A vibe de automação começou há alguns meses, quando em conversa identificamos alguns pontos preocupantes em relação à deploys. Se você deu uma lida nesse artigo do Diego Garcia, sabe como utilizamos o teresa para subir e acompanhar nossos apps nos clusters de K8s do Magalu.
Disparar deploys da nossa máquina via CLI agiliza bastante as publicações e reduz o nível de complexidade da tarefa, mas existem riscos.
Imagina se antes do deploy é feito o checkout de uma outra branch ou tag, ou algum arquivo é modificado localmente e é enviado em um estado diferente do repositório de código. A quantidade de trabalho humano (e propenso à erro) ligou um sinal de alerta, e começamos a pesquisar soluções para impedir que essas situações acontecessem de fato.
Foi aí então que optamos por subir uma instância de Jenkins para a tribo com o CLI do teresa devidamente configurado. Já tínhamos agora um “ambiente esterilizado” para realizar todos os nossos deploys.
Pra aumentar a segurança do processo de desenvolvimento, criamos algumas guidelines para os jobs:
- Toda nova feature seria automaticamente publicada no ambiente de sandbox após o merge, sem necessidade de intervenção de um membro da equipe para impedir que apps ficassem desatualizados.
- Todos os jobs de deploy em sandbox deveriam ser com base em uma branch.
- Todos os jobs de deploy em produção deveriam ser com base em uma tag.
Com isso nossa lista de jobs foi crescendo (na data deste artigo, eram 115). Além de deploys, outros jobs foram surgindo como geração de releases e outros processos que antes precisavam ser realizados de maneira manual pela equipe em algumas situações específicas.
Removendo gargalos e facilitando o uso da automação
Problemas com deploys sanados, começamos a atacar gargalos dentro dos times: processos centralizados em uma única pessoa. Começamos a automatizar esses processos para que qualquer membro do time pudesse executá-lo com autonomia.
E conforme a gama de processos cresceu, foi identificado um possível problema de acesso: Nem sempre um membro do time pode estar próximo do seu notebook com VPN. Como facilitar para que ele consiga disparar um processo sem deixar o nosso Jenkins aberto ao mundo?
A solução: criar um slackbot! Podemos nem sempre estar próximo de um notebook, mas nos dias de hoje é muito raro estarmos longe dos nossos celulares. Daí a idéia do chatbot! O bot foi escrito em Golang com a lib Slacker.
Show me the code!
O conceito dessa lib é bastante simples: Definimos comandos para que o bot “escute” no canal, e para cada comando registramos um Handler (que nada mais é do que uma função com a assinatura específica). Abaixo, um exemplo do corpo do bot
O comando Default é executado sempre que o comando enviado por um usuário não seja compreendido pelo bot. Abaixo, um exemplo:
Basta implementar uma função com a mesma assinatura que a da função acima e pronto!
Note que o Slacker nos dá acesso à algumas características bastante legais da API do Slack, como na linha 11 onde está sendo chamada a função Typing(). Esta função faz com que fique visível para todos os presentes no canal que o bot está “escrevendo uma resposta” ao receber o comando. Legal né?
E como temos o plugin de notificações de slack configurado no Jenkins, sabemos se o job rodou com sucesso ou não:
Acabamos adicionando outras funcionalidades como não permitir que comandos fossem executados pelo bot fora do canal oficial de CI da tribo, permissionamento de comandos, entre outras coisas. Bom, por hoje é isso! Pra não ficar muito longo, no próximo artigo eu prometo em mostrar como fazer disparo de jobs do Jenkins via API blz?
Um abraço à todos!
