← Central de ajuda

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.

  1. No seu projeto do DevOps: Project Settings, Service Hooks, botão de criar assinatura.
  2. Serviço Web Hooks, ação Post via HTTP.
  3. 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.
  4. 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.
  5. 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á.