-
Notifications
You must be signed in to change notification settings - Fork 5
Arbeitsvorrat Sentry
Hier eine kurze Beschreibung, wie ihr vorgehen könnt um Issues in Sentry in einer sinnvollen Reihenfolge abzuarbeiten:
Ich würde vorschlagen, Issues auf diesen drei Achsen anzugehen:
-
Sortieren nach Häufigkeit (Anzahl Events) (Dies sind Issues, die Häufig auftreten, und daher wahrscheinlich viele unserer Kunden betreffen)
Query:sort=freq
-
Sortieren nach Last Seen (Issues die fast sicher noch nicht gelöst sind, sonst würden sie nicht mehr auftreten) Query: last seen
-
Issues die in einem bestimmten Release das erste Mal aufgetreten sind. (Von jüngstem zu älteren Releases abarbeiten - Fehler die erst vor kurzem eingebaut wurden, sind i.d.R. auch einfacher wieder auszubauen und man erinnert sich eher noch daran, wo vor kurzem etwas angepasst wurde)
Queries: 2018.4.0.dev0
2018.3.6.dev0 2018.3.5.dev0 2018.3.5 (Aktueller Relrease bei SG) 2018.3.4 2018.3.2 2018.3.1 2018.3.0.dev0
2017.6.8 (Aktueller Release bei ZG)
-
❗️ Zuerst schauen, ob die Sentry Issue schon Kommentare und/oder eine verlinkte GitHub issue hat
-
Die Issue sich selbst assignen
-
Kurz eine Suche durchführen, ob es vielleicht schon eine Issue gibt die resolved ist, aber fälschlicherweise nicht zusammen gruppiert wurde. Falls ja, und definitiv klar ist, dass es sich um das selbe Problem handelt (und auch dieselbe Lösung), diese issues mergen. Im Zweifelsfall bitte nachfragen, Sentry events können nicht mehr unmerged werden!
-
Herausfinden, was genau für ein Problem besteht
-
Falls das Problem durch eine Anpassung im Code (commit in
og.core
) gelöst werden kann/muss:- Identifizieren, wie das Problem reproduziert werden kann/konnte (steps to reproduce)
- Nachdem klar ist, wie das Problem reproduziert werden kann:
- Prüfen, ob das Problem im aktuellen
master
ebenfalls noch reproduziert werden kann
- Prüfen, ob das Problem im aktuellen
-
Falls das Problem noch besteht, GitHub issue (via Button in Sentry) mit "steps to reproduce" erfassen
-
Falls nicht: PR ausfindig machen welcher das Problem gelöst hat, in die Sentry issue kommentieren (z.B. so) und Issue auf die entsprechende Version resolven.
-
Issue unassignen (ihr must nicht zwangsläufig die issue gleich lösen, ggf. kann dies auch jemand anders) und Erkenntnisse als Kommentar hinterlassen.
- PR mit dem Fix erstellen, und die erstellte Issue closen. Nachdem der PR gemerged ist, Sentry issue auf den entsprechenden Release resolven, PR in Kommentar hinterlassen.