Skip to main content

Eseguire il debug di un bug report end-to-end

Fornisci a Devin un bug report con log Datadog e accesso al database e ottieni un'analisi della causa principale e una PR con la correzione.
AuthorCognition
CategoryGestione degli incidenti
FeaturesMCP
1

Collega Datadog

Devin ha bisogno di accedere ai log di Datadog per cercare errori relativi al bug. Se non l’hai già fatto, abilita il Datadog MCP:
  1. Vai su Settings > MCP Marketplace e trova Datadog
  2. Fai clic su Enable e fornisci due segreti:
  3. Se la tua istanza Datadog usa un sito personalizzato (ad es. datadoghq.eu), imposta anche DATADOG_SITE
Una volta connesso, Devin può cercare nei log, recuperare tracce di errore e correlare i problemi con i deploy — tutto all’interno della sessione. Consulta MCP Marketplace per tutti i dettagli sulla configurazione.
2

Concedi a Devin l’accesso in sola lettura al database

Per i bug sui dati — valori errati, campi mancanti, query non funzionanti — Devin è molto più efficace quando può verificare direttamente lo stato dei dati. Fornisci una stringa di connessione di sola lettura come Secret:
  1. Vai su Settings > Secrets e aggiungi un nuovo secret:
    • Name: DATABASE_READ_REPLICA_URL
    • Value: postgresql://readonly_user:password@read-replica.internal:5432/production
  2. Aggiungi una nota come: “Connessione di sola lettura alla read replica di produzione. Da usare solo per query SELECT.”
In alternativa, collega un database MCP (PostgreSQL, MySQL, ecc.) in Settings > MCP Marketplace — Devin può usare entrambi gli approcci per interrogare i tuoi dati.
Usa sempre una read replica o un utente con permessi di sola SELECT. Devin non ha mai bisogno di accesso in scrittura per analizzare un bug. Se sei preoccupato che query costose possano incidere sulle prestazioni, configura Devin perché utilizzi una read replica dedicata o una replica analitica esistente separata dal tuo database di produzione.
3

Invia a Devin il bug report

Incolla il bug report direttamente in una sessione di Devin. Includi tutto il contesto fornito da chi l’ha segnalato — quando è iniziato, chi è interessato, cosa non funziona e dove. Per un’indagine strutturata, usa il !triage template playbook — duplicalo e personalizza i passaggi per il tuo stack.Più il bug report è specifico, più velocemente Devin trova la risposta. “Dal deploy di venerdì” permette a Devin di restringere la finestra temporale in Datadog. “Utenti del piano Pro” gli indica esattamente quali record interrogare.
4

Devin indaga e risolve

Con Datadog e l’accesso al database configurati, Devin esegue un’indagine completa:Estrae i log di Datadog — Cerca errori sul servizio di fatturazione a partire da venerdì, filtrando per nome del servizio e stato di errore. Trova un picco di TypeError: Cannot read property 'name' of undefined a partire dalle 18:12 UTC nella data del deploy.Interroga il database — Esegue SELECT id, company_name, plan FROM users WHERE plan = 'pro' LIMIT 20 sulla replica in sola lettura. Conferma che gli utenti Pro hanno valori company_name — i dati sono corretti, quindi il bug è nel codice.Rintraccia la modifica al codice — Controlla git log --since="2026-02-13" e trova il commit a1b2c3d che ha eseguito un refactoring della risposta dell’API utente, rinominando company in organization. La pagina di fatturazione in src/pages/billing/BillingHeader.tsx fa ancora riferimento a user.company.name.Scrive la correzione — Aggiorna BillingHeader.tsx per usare user.organization?.name ?? 'Your Company' e aggiunge un test di regressione che renderizza il componente sia con la vecchia sia con la nuova struttura della risposta dell’API.Verifica nel browser — Avvia il server di sviluppo, apre la pagina di fatturazione nel browser integrato di Devin e conferma che il nome dell’azienda ora viene visualizzato correttamente per un utente di test.Apre una PR con la correzione, il test e una descrizione che spiega la causa principale e l’impatto (tutti gli utenti Pro ed Enterprise, ~350 account).
5

Follow-up

Una volta che la PR di correzione è stata unita (merged), puoi chiedere a Devin di cercare problemi correlati o di aggiungere monitoraggio:Se vuoi che Devin ricordi qualcosa emerso da questa indagine per la prossima volta, diglielo semplicemente — ad esempio, “Ricorda che l’API utente usa user.organization, non user.company.” Devin proporrà una voce di Knowledge che puoi rivedere e salvare. In questo modo, le sessioni future inizieranno già con il contesto che il tuo team ha acquisito.