Skip to main content

Einen Bug-Report End-to-End debuggen

Gib Devin einen Bug-Report mit Datadog-Logs und Datenbankzugriff und erhalte eine Root-Cause-Analyse sowie einen Fix-PR.
AuthorCognition
CategoryIncident Response
FeaturesMCP
1

Mit Datadog verbinden

Devin benötigt Zugriff auf Ihre Datadog-Logs, um nach Fehlern im Zusammenhang mit dem Bug zu suchen. Falls Sie das noch nicht getan haben, aktivieren Sie den Datadog MCP:
  1. Gehen Sie zu Settings > MCP Marketplace und suchen Sie Datadog
  2. Klicken Sie auf Enable und geben Sie zwei Secrets an:
  3. Wenn Ihre Datadog-Instanz eine benutzerdefinierte Site verwendet (z. B. datadoghq.eu), setzen Sie zusätzlich DATADOG_SITE
Sobald die Verbindung steht, kann Devin Logs durchsuchen, Fehlertraces abrufen und Probleme mit Deployments korrelieren – alles innerhalb der Sitzung. Vollständige Einrichtungsdetails finden Sie im MCP Marketplace.
2

Gewähren Sie Devin Lesezugriff auf die Datenbank

Bei Datenfehlern – falsche Werte, fehlende Felder, fehlschlagende Abfragen – ist Devin deutlich effektiver, wenn es den Datenzustand direkt verifizieren kann. Übergeben Sie einen schreibgeschützten Connection-String als Secret:
  1. Gehen Sie zu Settings > Secrets und fügen Sie ein neues Secret hinzu:
    • Name: DATABASE_READ_REPLICA_URL
    • Value: postgresql://readonly_user:password@read-replica.internal:5432/production
  2. Fügen Sie eine Notiz hinzu wie: “Schreibgeschützte Verbindung zur Read-Replica der Produktionsdatenbank. Nur für SELECT-Abfragen geeignet.”
Alternativ können Sie eine Datenbank-MCP (PostgreSQL, MySQL, etc.) unter Settings > MCP Marketplace verbinden – Devin kann beide Ansätze verwenden, um Ihre Daten abzufragen.
Verwenden Sie immer eine Read-Replica oder einen Benutzer mit ausschließlich SELECT-Berechtigungen. Devin benötigt keinen Schreibzugriff, um einen Bug zu untersuchen. Wenn Sie befürchten, dass ressourcenintensive Abfragen die Performance beeinträchtigen, richten Sie Devin auf eine dedizierte Read-Replica oder eine bestehende Analytics-Replica aus, die von Ihrer Produktionsdatenbank getrennt ist.
3

Sende den Fehlerbericht an Devin

Füge den Bug-Report direkt in eine Devin-Session ein. Nimm so viel Kontext auf, wie der*die Meldende dir gegeben hat – wann es angefangen hat, wer betroffen ist, was genau falsch läuft und wo. Für eine strukturierte Analyse verwende das !triage-Template-Playbook – dupliziere es und passe die Schritte an deinen Stack an.Je konkreter der Fehlerbericht, desto schneller findet Devin die Antwort. „Seit dem Deployment am Freitag“ ermöglicht es Devin, das Datadog-Zeitfenster einzugrenzen. „Pro-Tarif-Nutzer“ sagt Devin genau, welche Datensätze abgefragt werden sollen.
4

Devin analysiert und behebt

Mit angebundenem Datadog und eingerichtetem Datenbankzugriff führt Devin eine vollständige Untersuchung durch:Ruft Datadog-Logs ab — Sucht seit Freitag nach Fehlern im Billing-Service, gefiltert nach Servicename und Fehlerstatus. Findet einen Anstieg von TypeError: Cannot read property 'name' of undefined ab 18:12 UTC am Deployment-Tag.Fragt die Datenbank ab — Führt SELECT id, company_name, plan FROM users WHERE plan = 'pro' LIMIT 20 gegen das Read-Replica aus. Bestätigt, dass Pro-Benutzer tatsächlich company_name-Werte haben — die Daten sind in Ordnung, der Bug steckt also im Code.Verfolgt die Code-Änderung — Prüft git log --since="2026-02-13" und findet den Commit a1b2c3d, der die Antwort der User-API refaktorisiert und company in organization umbenannt hat. Die Billing-Seite unter src/pages/billing/BillingHeader.tsx referenziert weiterhin user.company.name.Implementiert den Fix — Aktualisiert BillingHeader.tsx, um user.organization?.name ?? 'Your Company' zu verwenden, und fügt einen Regressionstest hinzu, der die Komponente sowohl mit der alten als auch mit der neuen API-Response-Struktur rendert.Verifiziert im Browser — Startet den Dev-Server, öffnet die Billing-Seite im integrierten Browser von Devin und bestätigt, dass der Firmenname nun für einen Testbenutzer korrekt gerendert wird.Öffnet einen PR mit dem Fix, dem Test und einer Beschreibung, die die Root Cause und die Auswirkungen erklärt (alle Pro- und Enterprise-Nutzer, ~350 Accounts).
5

Nächste Schritte

Sobald der PR mit dem Fix zusammengeführt ist, kannst du Devin bitten, nach verwandten Issues zu suchen oder Monitoring hinzuzufügen:Wenn du möchtest, dass Devin sich beim nächsten Mal etwas aus dieser Untersuchung merkt, sag es ihm einfach — z. B. “Remember that the user API uses user.organization, not user.company.” Devin schlägt einen Knowledge-Eintrag vor, den du überprüfen und speichern kannst. So starten zukünftige Sitzungen bereits mit dem Kontext, den dein Team sich schon erarbeitet hat.