Depurar um Relatório de Bug de Ponta a Ponta
Entregue à Devin um relatório de bug com logs do Datadog e acesso ao banco de dados, e receba de volta uma análise da causa raiz e um PR com a correção.Conectar ao Datadog
Devin precisa de acesso aos seus logs do Datadog para localizar erros relacionados ao bug. Se você ainda não fez isso, ative o MCP do Datadog:
- Vá para Settings > MCP Marketplace e localize Datadog
- Clique em Enable e forneça dois segredos:
DATADOG_API_KEY— na sua página de chaves de API do DatadogDATADOG_APP_KEY— na sua página de chaves de aplicação do Datadog
- Se sua instância do Datadog usa um site personalizado (por exemplo,
datadoghq.eu), defina tambémDATADOG_SITE
Conceda ao Devin acesso somente leitura ao banco de dados
Para bugs de dados — valores incorretos, campos ausentes, queries com erro — o Devin é muito mais eficiente quando consegue verificar diretamente o estado dos dados. Passe uma connection string somente leitura como um Secret:
- Vá em Settings > Secrets e adicione um novo secret:
- Name:
DATABASE_READ_REPLICA_URL - Value:
postgresql://readonly_user:password@read-replica.internal:5432/production
- Name:
- Adicione uma observação como: “Conexão somente leitura para a read replica de produção. Seguro apenas para queries SELECT.”
Envie o relatório de erro para o Devin
Cole o relatório de bug diretamente em uma sessão do Devin. Inclua o máximo de contexto que o relator forneceu — quando começou, quem é afetado, o que está errado e onde. Para uma investigação estruturada, use o
!triage template playbook — duplique-o e personalize as etapas para o seu stack.Quanto mais específico for o relatório, mais rápido o Devin encontra a resposta. “Since Friday’s deploy” permite que o Devin limite a janela de tempo no Datadog. “Pro plan users” diz exatamente quais registros consultar.Devin investiga e corrige
Com Datadog e acesso ao banco de dados conectados, Devin executa uma investigação completa:Coleta logs do Datadog — Procura por erros no serviço de cobrança desde sexta-feira, filtrando por nome de serviço e status de erro. Encontra um pico de ocorrências de
TypeError: Cannot read property 'name' of undefined começando às 18:12 UTC na data do deploy.Consulta o banco de dados — Executa SELECT id, company_name, plan FROM users WHERE plan = 'pro' LIMIT 20 na réplica de leitura. Confirma que usuários do plano Pro de fato têm valores em company_name — os dados estão corretos, então o bug está no código.Rastreia a alteração de código — Verifica git log --since="2026-02-13" e encontra o commit a1b2c3d que refatorou a resposta da API de usuários, renomeando company para organization. A página de cobrança em src/pages/billing/BillingHeader.tsx ainda faz referência a user.company.name.Escreve a correção — Atualiza BillingHeader.tsx para usar user.organization?.name ?? 'Your Company' e adiciona um teste de regressão que renderiza o componente tanto com o formato antigo quanto com o novo da resposta da API.Verifica no navegador — Inicia o servidor de desenvolvimento, abre a página de cobrança no navegador embutido do Devin e confirma que o nome da empresa agora é renderizado corretamente para um usuário de teste.Abre um PR com a correção, o teste e uma descrição explicando a causa raiz e o impacto (todos os usuários Pro e Enterprise, ~350 contas).Acompanhamento
Depois que a PR de correção for mesclada, você pode pedir ao Devin para procurar problemas relacionados ou adicionar monitoramento:Se você quiser que o Devin se lembre de algo desta investigação para a próxima vez, é só dizer — por exemplo: “Lembre-se de que a API de usuário usa
user.organization, não user.company.” O Devin vai propor uma entrada em Knowledge que você pode revisar e salvar. Assim, sessões futuras já começam com o contexto que sua equipe já aprendeu.