Azure DevOps: ligar ticket a tarefa de desenvolvimento
Atualizado em
Quem desenvolve trabalha no Azure DevOps e quem atende trabalha no supme, e o cliente que reportou o erro fica no meio. Esta integração fecha esse vão: o movimento do work item (Bug ou PBI) vira nota interna no ticket relacionado, sem ninguém copiar informação de um lado para o outro. Faz parte do plano Enterprise.
Como chegar
Menu lateral, grupo Integrações, item Azure DevOps. Sem a integração no plano, a tela mostra um cartão com cadeado e o botão Ver planos.
O que a ligação faz, nos dois sentidos
Do DevOps para o supme: quando um work item muda de estado, é fechado ou recebe comentário, entra uma nota interna no ticket relacionado. A nota é assinada como Sistema, o cliente nunca a vê, e o ticket sobe na fila por ter tido movimento. Ela traz o tipo e o número do work item, o título, a mudança de estado no formato "estado antigo para estado novo" (com o rótulo de fechado ou resolvido quando for o caso), o comentário recortado em até 1.200 caracteres, quem mexeu e um link para abrir o work item no DevOps.
Do supme para o DevOps: no detalhe do ticket, o cartão Azure DevOps deixa o atendente vincular um work item pelo número ou colando a URL dele. O vínculo vira um atalho clicável dentro do ticket e é o que faz o casamento funcionar quando o work item não menciona o ticket. O supme não cria nem edita work item: a ligação é de leitura e de referência.
Configurar o Service Hook
Aqui, ao contrário do WhatsApp, quem configura o outro lado é você. A tela mostra dois valores para copiar, e os dois são necessários.
- No seu projeto do DevOps: Project Settings, Service Hooks, botão de criar assinatura.
- Serviço Web Hooks, ação Post via HTTP.
- Gatilho Work item updated. Para receber também os comentários, crie uma segunda assinatura com Work item commented. Dá para filtrar por Area path ou Tags, se você não quiser o projeto inteiro.
- No campo URL, cole a URL que a tela mostra. Em HTTP headers, cole a linha inteira que a tela mostra, com o nome do header junto (o DevOps recusa o token sozinho). Deixe a autenticação básica em branco.
- Salve no DevOps, volte aqui e marque Receber movimentações do Azure DevOps. Teste movimentando um work item.
O token vai no header, e não na URL, para não ficar registrado nos logs de acesso pelo caminho. Trate a linha do header como senha.
Os controles da tela
- Receber movimentações do Azure DevOps: a chave do canal, que grava sozinha. Configure o Service Hook antes de ligar, senão você liga uma porta que não recebe nada.
- URL com o botão Copiar: o endereço público que o DevOps vai chamar.
- Linha pra colar em HTTP headers com o botão Copiar: o que você vê é a linha pronta, com nome do header e valor. O que se copia é exatamente ela.
- Novo token: gera um token novo e invalida o atual na hora. Use se desconfiar de vazamento, e lembre de atualizar o header no Service Hook logo depois, senão as movimentações param de chegar.
Como o supme sabe de qual ticket se trata
Duas formas, nesta ordem:
- Vínculo explícito, criado no cartão Azure DevOps do ticket. É o caminho mais confiável e o único que funciona sem tocar no work item.
- Número do ticket no work item, no formato SUP-123, escrito no título ou numa tag. É prático quando o work item nasce a partir do ticket.
Sem nenhuma das duas, a movimentação é ignorada em silêncio: não existe ticket para onde mandar a nota. Um work item só pode estar vinculado a um ticket, e tentar vincular o mesmo número duas vezes é recusado com aviso na tela.
O que confunde
- Nem toda edição vira nota. Só mudança de estado, fechamento ou resolução, e comentário. Trocar o responsável, mexer na estimativa ou corrigir a descrição não gera nada, para a linha do tempo do ticket não virar um diário do board.
- Criação e exclusão de work item não contam. O gatilho é sobre item atualizado ou comentado.
- A nota é interna. Nada disso aparece para o cliente. Quem avisa o cliente é o atendente, quando fizer sentido.
- Desligar a chave não desfaz os vínculos. As movimentações param de virar nota, mas os work items vinculados continuam listados nos tickets.
- Gerar token novo derruba o Service Hook antigo. Ele continua postando com o token velho, que deixou de valer, e nada chega até você atualizar o header lá.