Mesmo com todo o progresso de Thomas Lawless, engenheiro de software sênior da IBM, e de sua equipe no dia anterior, eles começavam todos os dias de trabalho verificando se havia código para revisar. “Era como se estivéssemos recriando o processo todas as manhãs”, ele diz.
Lawless é responsável por supervisionar a produção, implantação e entrega de alguns dos maiores apps de intranet da IBM. “Meu escopo abrange desenvolvimento, integração contínua, automação de testes, automação de implantação e operações”, explica, “o que significa que em um dia trabalho com 40 ou 50 pessoas diferentes, todas em equipes diferentes”.
“Temos o que chamamos de ‘fluxo de entrega de ponta a ponta’, que começa pelo código-fonte e percorre todo o processo até a implementação em produção”, diz Lawless. “Agora, integramos o Slack aos principais marcos desse processo.”
Um aspecto importante do trabalho de Lawless é introduzir técnicas e serviços de desenvolvimento para melhorar as operações e acelerar a entrega. Ele começou a usar o Slack com outras equipes na IBM há mais de um ano como uma central para comunicações, mas logo descobriu que a plataforma também é útil para reunir comunicações não humanas, como alertas de sistema e notificações de outros serviços.
“Temos o que chamamos de ‘fluxo de entrega de ponta a ponta’, que começa pelo código-fonte e percorre todo o processo até a implementação em produção” diz Lawless. “Agora, integramos o Slack aos principais marcos desse processo”.
Gerenciamento dos processos de compilação e implementação no Slack
Na IBM, as equipes tendem a usar canais públicos do Slack (por exemplo, #development-team) para que os membros da equipe possam discutir problemas abertamente e especialistas de outras equipes possam participar facilmente para dar sua contribuição.
Os canais da equipe contêm mensagens de pessoas, bem como alertas do sistema dos inúmeros apps usados. Digamos, por exemplo, que um desenvolvedor envia uma história de usuário para revisão do código-fonte. O sistema dispara uma notificação no canal da equipe no Slack informando a todos que há novo código para revisão. A pessoa responsável pode entrar no sistema para revisar o código diretamente na mensagem do Slack.
“Antes de usar o Slack, um desenvolvedor teria que encontrar quem ele achava que deveria ser o revisor e, em seguida, enviar um e-mail para tal pessoa ou iniciar um chat individual com ela”, diz Lawless.
Com os fluxos de trabalho das equipes passando pelo Slack, as pessoas podem acompanhar o progresso do trabalho sabendo que serão notificadas sobre revisões de código individuais conforme necessário e que podem dar conhecimento e começar a abordar a questão diretamente no Slack.
Mobilização de equipes em torno de alertas de sistema para um melhor gerenciamento de incidentes
Confira alguns canais de equipes populares na IBM e os tipos de conversas e notificações que acontecem por lá:
#help-services: coleta notificações de pull request (PR) para facilitar revisões automatizadas de código entre pares e alerta a equipe quando a solicitação é aprovada, evitando que membros da equipe tenham que alternar entre apps para conferir a última atualização. A equipe também conta com a integração Jenkins /Travis CI para receber notificações quando o status de uma compilação muda.#help-deployments: os membros da equipe recebem notificações sobre implantações com falha à medida que as alterações de código passam pela automação de testes.#help-tasks: posta notificações quando há falhas em trabalhos de processamento em lote.#starfleet-monitoring: para monitoramento de tempo de execução e gerenciamento de incidentes. Notificações do NewRelic, Splunk e PagerDuty são enviadas a esse canal.
“O canal serve como uma espécie de trilha de auditoria”, diz Lawless. “Nós usamos esses canais de incidentes como a raiz da nossa análise depois de um evento e, o que é ótimo, não precisamos adivinhar, pois temos todo o histórico à nossa disposição.”
Lawless explica que quando um alerta sobre uma falha ou um incidente aparece no Slack, os membros da equipe responsáveis iniciarão um novo canal específico para o incidente onde poderão discutir possíveis soluções e onde qualquer pessoa poderá convidar outros especialistas, conforme necessário.
Quando o problema é resolvido, a equipe tem um registro de todo o incidente, incluindo todos os arquivos, capturas de tela, mensagens de erro e alertas discutidos enquanto trabalhavam em uma solução.
“O canal serve como uma espécie de trilha de auditoria”, diz Lawless. “Nós usamos esses canais de incidentes como a raiz da nossa análise depois de um evento e, o que é ótimo, não precisamos adivinhar, pois temos todo o histórico à nossa disposição.”
Mais recentemente, Lawless e sua equipe começaram a usar o Slack com fornecedores dos diversos serviços que usam. Ele descobriu que a maioria das empresas fica satisfeita em compartilhar um canal privado do Slack entre suas equipes para conversar sobre problemas e perguntas que possam ter, o que evita uma excessiva troca de mensagens.
Menos etapas extras geram grandes ganhos de produtividade
Lawless e sua equipe integraram o Slack em todas as etapas do processo de desenvolvimento, desde a escrita e teste do código-fonte inicial até a implantação final. Em vez de passar as manhãs verificando novos códigos para revisar, todos retomam de onde pararam no dia anterior.
“Sempre que vejo uma integração do Slack, eu a ativo”, diz Lawless. “Ela agrega muito mais valor e nos ajuda a economizar várias etapas adicionais no processo.”
