Sentry React Native: 2026 Integration Guide

Sie haben eine React Native-Anwendung lokal laufen, die QA hat zugestimmt und die Produktion ist nah. Dann landet die offensichtliche Frage: Was passiert, wenn sie auf einem Gerät des Benutzers kaputt geht?

Ohne Sentry ist die Antwort normalerweise schlecht. Sie erhalten ein Support-Ticket, ein vages Screenshot, vielleicht ein Konsole-Log von einem Entwickler-Builder, der nicht mit der Produktion übereinstimmt. Mit Sentry React Native eingerichtet, erhalten Sie den Fehler, die Stack, die Veröffentlichung, die sie verschickt hat, und genug Kontext, um sie ohne Vermutungen zu beheben. Der Haken ist, dass die grundlegende Installation die leichtere Seite ist. Die schmerzhaften Teile kommen später: native Integration, Symbolisierung, Quellkarten, Veröffentlichungsbenennung und das Aufrechterhalten aller davon, wenn Ihr Liefermodell Live-Updates beinhaltet.

Die meisten Leitfäden stoppen zu früh. Eine echte Einrichtung muss CI, App-Store-Builds, Android-Veröffentlichungen und JavaScript-Bundles überstehen, die nicht immer aus dem Original-Datei stammen.

Tabelle der Inhalte

• Zum Starten mit der Sentry SDK
  • Was Sie benötigen, bevor Sie installieren
  • Das Wizard ausführen und das Ergebnis überprüfen
• Konfigurieren von Native iOS- und Android-Projekten
  • Was sich auf iOS geändert hat
  • Was sich auf Android geändert hat
  • Native-Einstellungen, die Ihnen später Zeit sparen
• Automatisieren von Releases und Source Maps
  • Warum Uploads manuell fehlschlagen
  • Eine Release-Prozess, der tatsächlich funktioniert
  • Eine praktische CI-Skriptmuster
• Leistungsmessung und Ereignisse anpassen
  • Tracing a slow screen instead of guessing
  • Fehlermeldungen mit nützlichen Kontexten versehen
• Ihr Integration überprüfen und Fehler beheben
  • Sichere Testereignisse auslösen
  • Was Sie im Sentry-UI überprüfen sollten
  • Häufige Probleme bei der React Native-Integration
• Integrieren mit Live-Update-Workflows wie Capgo
  • Release-Identifikatoren mit Live-Bundles abgleichen

Getting Started with the Sentry SDK

Die schnellste Möglichkeit, Sentry React Native in ein neues Projekt zu integrieren, ist immer noch der Installations-Assistent. Er handhabt den größten Teil der wiederholten Einstellungen und bringt Sie schnell zu einem funktionierenden Grundlayout. Das zählt, weil die manuelle Einarbeitung der ersten Installation normalerweise zu kleinen Abweichungen führt, die Sie erst bei der ersten Produktionsstörung bemerken.

Was Sie vor der Installation benötigen

Zunächst benötigen Sie ein normales React Native-Entwicklungsumfeld. Node, ein Paketmanager, Plattform-Tools für iOS und Android sowie Watchman auf macOS, wenn dies bereits Teil Ihres Workflows ist. Sie benötigen auch ein Sentry-Konto und ein für React Native erstelltes Projekt.

If Sie noch entscheiden, ob React Native die richtige Betriebswahl für Ihr Team ist, lesen Sie diesen React Native-Leitfaden für Unternehmen erläutert nützliche, nicht-marketingbezogene Kontextinformationen zu Plattform-Abwägungen, Personal und Wartungserwartungen. Es lohnt sich, ihn vor der Verpflichtung Ihres Überwachungs- und Releaseprozesses um eine gemeinsame Codebasis zu lesen.

Installieren Sie die SDK mit dem Zauberer aus dem Projektroot:

npx @sentry/wizard@latest -i reactNative

Der Zauberer fragt ein paar Dinge, die Entwickler oft zu schnell durchklicken:

• ProjektwahlWählen Sie das tatsächliche Sentry-Projekt, das Sie in der Produktion verwenden möchten, und nicht ein temporärer Sandbox, den Sie später vergessen werden.
• Native ÄnderungenJa sagen. JavaScript-basierte Fehlerfänge sind für mobile Apps nicht ausreichend.
• Optionale FunktionenWählen Sie nur die Funktionen, die Sie wissen, dass Sie verwenden werden, aber nicht alles blind auf den ersten Tag aktivieren, wenn Ihr Team die resultierenden Daten nicht überprüfen wird.

Das Ausführen des Zauberers und das Überprüfen des Ergebnisses

After dem Zauberer ist fertig, überprüfen Sie die Änderungen anstatt ihnen ohne Überprüfung zu vertrauen. Sie sollten ein Sentry-Paket in package.json, native Änderungen unter ios und android, und eine Initialisierungsbloque in Ihrem Anwendungsstartdatei sehen.

Eine typische Initialisierung sieht so aus:

import * as Sentry from '@sentry/react-native';

Sentry.init({
  dsn: 'YOUR_DSN',
});

Die DSN zeigt dem SDK , wohin Ereignisse gesendet werden sollen. Behandeln Sie es als Konfiguration, nicht als ein Geheimnis, das niemals sichtbar sein darf. Es ist nicht dasselbe wie ein Authentifizierungstoken. Halten Sie jedoch Ihre Umgebungs-Einstellungen sauber und konsistent, damit Ihre App auf die richtige Sentry-Projekt in jeder Umgebung zeigt.

Eine praktische Muster ist, die DSN aus Umgebungs-spezifische Konfiguration zu laden und Sentry vor dem Rest Ihrer App Baum zu initialisieren. Wenn Sie auch durch die Start-Up-Polish arbeiten, ist diese Anleitung zu React Native Splash Screen Setup nützlich, weil die Start-Up-code-Reihenfolge oft mit dem Ort überschneidet, an dem Teams Sentry-Initialisierung platzieren.

Praktische Regel: initialize Sentry so früh wie möglich in der Anwendungsstartphase. Wenn Sie bis zum Navigieren, Authentifizierungshydratation oder Remote-Konfiguration warten, werden Sie Fehlstarts während der Startphase verpassen.

Zu diesem Zeitpunkt sollten Sie sich nicht auf Vollkommenheit konzentrieren. Das unmittelbare Ziel ist einfach: Lassen Sie die App starten, lösen Sie später in diesem Artikel einen JavaScript-Fehler aus und bestätigen Sie, dass Ereignisse bei Sentry ankommen. Sobald das funktioniert, werden die native und die Release-Schichten viel einfacher zu verstehen.

Konfiguration von Native iOS- und Android-Projekten

Zu diesem Zeitpunkt erhalten viele React Native-Teams einen falschen Eindruck der Vollendung. Das JavaScript-SDK ist installiert, Ereignisse erscheinen und jeder nimmt an, dass die Fehlerberichterstattung abgeschlossen ist. Das ist nicht der Fall. Wenn die native Integration ausgeschaltet ist, werden einige der Fälle, die Sie am meisten interessieren, nie in einer verwendbaren Form bei Sentry ankommen.

Wat hat sich auf iOS geändert

Öffnen Sie das iOS-Projekt und überprüfen Sie, was der Zauberer geändert hat. In einer leeren React Native-Anwendung bedeutet das meist Updates in Bezug auf die Anwendungsstartphase und die Buildphasen. Sie suchen nach Sentry-Initialisierungsschleifen und Uploadschritten, die mit Ihrem Build-Prozess verbunden sind.

In Xcode überprüfen Sie diese Orte:

• App-Delegate-Start-codeDie App benötigt eine native Sentry-Initialisierung frühzeitig bei der Startphase.
• Build-PhasenSuchen Sie nach einem Sentry-Upload-Script, das mit Debugsymbolen oder Sourcemaps-Handling verbunden ist.
• Build-Einstellungen und Archivverhalten. Symbol files müssen generiert und während der Archivierung verfügbar sein.

Wenn Ihre App AppDelegate.mm verwendet, sitzt die Initialisierung oft in der Nähe der Bootstrapping des React Native Bridge.

Der genaue Dateiinhalt kann je nach React Native Version, Template und Verwendung der neuen Architektur variieren, daher sollten Sie keine Snippets aus zufälligen Repositories kopieren, es sei denn, sie passen Ihrer Projektstruktur.

Was zählt ist der Zweck: iOS-native Crashs benötigen Symbol-Daten, und die App muss Sentry vor dem Beobachten des Crashs starten.

Wenn iOS-Crashs in Sentry mit nicht lesbaren native Frames erscheinen, ist das Problem meist nicht "Sentry ist kaputt." Es ist die Symbol-Upload oder Release-Matching.

Was sich auf Android geändert hat android/build.gradle, android/app/build.gradleAndroid ändert sich normalerweise in den Gradle-Dateien und manchmal in der Manifest-Ebene-Konfiguration. Überprüfen Sie

und jede Sentry-zugeteilte Plugin- oder Aufgaben-Verdrahtung.

1. Dinge zu überprüfen: Die Sentry-Gradle-Plugin ist angewendet
2. damit Release-Artikel während der Build-Zeit verarbeitet werden können. Die Variante-Verwaltung ist sinnvoll. Wenn Sie Produktflavours oder mehrere Buildtypen verwenden.
3. ProGuard- oder R8-Ausgaben werden berücksichtigt Wenn Ihre Release-Builds code komprimieren oder verschleieren.

Ein häufiger Fehler bei Android ist das Annehmen, dass ein erfolgreicher lokaler Debug-Test beweist, dass die Release-Konfiguration korrekt ist. Das tut sie nicht. Der Release-Weg ist anders, insbesondere wenn Minifizierung und CI-Signierung im Spiel sind. Wenn Ihr Team separate Debug-, Staging-, QA- und Store-Builds verwaltet, ist dieser Überblick über die Mobilbauarten ist eine nützliche Referenz für die Anpassung der Überwachungsverhalten an jede Build-Variante.

Native-Einstellungen, die Zeit sparen

Stopp nicht bei „Der Zauberer hat Dateien geändert.“ Überprüfe das Verhalten direkt.

Verwende diese Liste:

• Archivieren Sie eine iOS-Build lokal und bestätigen Sie, dass die Build nicht während der Symbolverarbeitung fehlschlägt.
• Erstellen Sie eine Release-Android-Build und die CI-Protokolle für Sentry-zuweisbare Aufgaben überprüfen.
• Überprüfen Sie die Paketnamen- und Bundle-Identifier-Zuweisung in Sentry, wenn Sie mehrere Apps unter einer Organisation verwalten. Bestätigen Sie die Versionsbezeichnungs-Konventionen jetzt
• Bevor die CI Artefakte unter inkonsistenten Namen hochlädt.Hier ist, was normalerweise nicht gut funktioniert:

Ansatz

Die beste Konfiguration ist langweilig. Native-Startupschleifen sind im Gange, Build-Skripte laufen jeden Tag und die Release-Namen sind deterministisch über iOS, Android und JavaScript-Bundles.

Automatisierung von Releases und Source Maps

Wenn es einen Ort gibt, an dem Sentry React Native-Einstellungen auseinanderbrechen, ist es hier. Teams installieren den SDK, sehen Ereignisse und verzögern die Automatisierung von Releases. Dann kommt das erste ernsthafte Produktionsproblem herein und die Stack-Spur ist minimiert, das Release fehlt oder die Upload-Datei für die Source Map gehört zu einem anderen Bundle.

Warum manuelle Uploads in der Praxis scheitern

Die Scheitelpunkte sind vorhersehbar:

Jemand vergisst, die Maps hochzuladen

• nach einer spätnächtlichen Hotfix. Die hochgeladenen Dateien gehören zu einem anderen Commit
• als das Binary oder OTA-Bundle, das die Benutzer ausführen. Die Fehlerarten sind vorhersehbar:
• Die Versionsbezeichnung ändert sich leicht zwischen iOS, Android und CI-Schritten.
• Eine Neuverteilung erfolgt nach dem Upload von Map-Dateien und ungültigt, was Sentry gegenüber abgleichen soll.

Deshalb empfehle ich nicht die „Schritte in Notion dokumentieren“-Methode. Sie funktioniert, bis ein dringender Release unter Druck herausgeht.

Ein Release-Prozess, der wirklich hält

Ein zuverlässiger Setup hat einige Eigenschaften:

• Release-IDs werden einmal generiert und überall wieder verwendet.
• Build-, Bundle- und Upload-Schritte finden in derselben Pipeline statt.
• Quellkarten werden von CI hochgeladennicht von einem Entwickler-Notebook.
• Die App initialisiert Sentry mit dem gleichen Release-String, den CI während des Uploads verwendet hat.

Das letzte Punkt ist wichtiger als oft angenommen. Sie benötigen nicht nur Sourcemaps in Sentry. Sie benötigen die korrekten Sourcemaps, die an dem exakt Release-Identifikator angehängt sind, der vom App am Laufzeitpunkt ausgegeben wird..

Wenn Ihr Team bereits mobile Automatisierung standardisiert, passt sich dieser Leitfaden zur automatischen Build- und Release-Workflows mit GitHub Actions perfekt in das gleiche Betriebsmodell.

Ein praktisches CI-Skriptmuster

Verwenden Sie ein Skript wie dieses in CI und füttern Sie Werte aus Ihrem Pipeline-Umgebung:

#!/usr/bin/env bash
set -euo pipefail

export SENTRY_AUTH_TOKEN="$SENTRY_AUTH_TOKEN"
export SENTRY_ORG="your-org"
export SENTRY_PROJECT="your-project"

RELEASE_NAME="${APP_VERSION}+${GIT_SHA}"

npx sentry-cli releases new "$RELEASE_NAME"

npx react-native bundle \
  --platform ios \
  --dev false \
  --entry-file index.js \
  --bundle-output ./dist/main.jsbundle \
  --sourcemap-output ./dist/main.jsbundle.map

npx sentry-cli releases files "$RELEASE_NAME" upload-sourcemaps ./dist \
  --rewrite \
  --strip-prefix "$(pwd)"

npx sentry-cli releases finalize "$RELEASE_NAME"

Sie werden das Bundle-Befehl für Android anpassen müssen und viele Teams teilen Plattform-spezifische Jobs anstatt, eine Skript zu zwingen, beide zu tun. Das ist in Ordnung. Was zählt ist Konsistenz.

Disziplin bei der Release-Verwaltung schlägt cleveres Scripting. Wählen Sie eine Namenskonvention, injizieren Sie sie in die App bei der Buildzeit und lassen Sie keine lokalen ad-hoc-Uploads mit CI konkurrieren.

Für React Native bevorzuge ich die Speicherung der Release-String in einer build-generierten Konfigurationslocation und die Lesung während Sentry.init():

Sentry.init({
  dsn: Config.SENTRY_DSN,
  release: Config.SENTRY_RELEASE,
  dist: Config.SENTRY_DIST,
});

Der Gewinn ist einfach. Wenn ein Ereignis eintritt, kann Sentry die minimierte Frame zurück auf den code mappen, den Sie verschickt haben, und nicht auf den code , den Sie glauben, verschickt zu haben.

Leistungsmessung und benutzerdefinierte Ereignisse erfassen

Crashes sagen Ihnen, was gebrochen ist. Leistungstracing sagt Ihnen, was Benutzer vorher gefühlt haben, bevor sie aufgaben.

Ein gängiger Bericht klingt wie folgt: „Die Dashboard ist langsam.“ Das ist nicht genug, um zu debuggen. Langsam wo? Bei der Navigation? Während der Datenabfrage? Während der Renderung eines schweren Charts? Sentry wird hier nützlich, wenn Sie aufhören, es wie einen Fehlerposteingang zu behandeln und anstatt dessen das Verhalten der App instrumentieren.

Stattdessen die Leistung eines langsamen Bildschirms nachverfolgen, anstatt zu raten

Beginnen Sie damit, die Leistungstracing in Ihrer Initialisierung zu aktivieren. Die genaue Abtaststrategie hängt von Ihrem Umfeld und Ihrem Volumenstoleranz, aber die Struktur sieht wie folgt aus:

Sentry.init({
  dsn: Config.SENTRY_DSN,
  tracesSampleRate: 1.0,
});

Wenn Sie React Navigation verwenden, integrieren Sie die Integration so, dass die Bildschirmübergänge Trace-Daten erzeugen. Dann reproduzieren Sie den Vorwurf auf einem physischen Gerät, nicht nur auf einem Simulator. Simulatoren verbergen den Art der Schläfrigkeit, die Benutzer bemerken.

Ein praktisches Dashboard-Beispiel:

1. Ein Benutzer öffnet das Hauptdashboard nach dem Anmelden.
2. Navigation wird abgeschlossen, aber der Inhalt erscheint verspätet.
3. Die Spur zeigt, dass die Bildschirmtransaktion lang ist.
4. Kinder-Spans offenbaren einen API-Anfrage und einen teuren Render-Path.
5. Sie optimieren den Render-Path, schicken ihn erneut und vergleichen die neue Spur-Form.

Das ist besser als aus dem Bauch zu fühlen.

Für Teams, die breit über Webview- oder Hybrid-App-Monitoring-Muster nachdenken, ist diese Schrift über Leistungsmessung in Capacitor-Projekten würdig, durchzublättern, weil der operative Mindset ähnlich ist, obwohl die Stacks sich unterscheiden.

Hinzufügen von nützlichem Kontext zu Fehlern

Leistungsdaten werden nützlicher, wenn Ereignisse Geschäfts-Kontext tragen. Nicht Vanität-Metadaten. Nur genug, um zu beantworten, wer betroffen war, auf welcher Seite sie waren und was vor dem Scheitern passierte.

Benutzen Sie diese Tools absichtlich:

• Benutzer-Kontext mit Sentry.setUser() damit die Unterstützung Berichte an einen betroffenen Account ohne Raten korrelieren kann.
• Breadcrumbs für Aktionen wie das Anklicken von
• Custom tags für Dimensionen wie Plan-Typ, Feature-Flag-Zustand oder API Region.
• Fehlgeschlagene Ausnahmen mit zusätzlichen Kontext bei der Fehlerrückgewinnung oder der Oberflächenerfassung kontrollierter Fehler.

Beispiel:

Sentry.setUser({
  id: user.id,
  email: user.email,
});

Sentry.addBreadcrumb({
  category: 'navigation',
  message: 'Opened dashboard screen',
  level: 'info',
});

try {
  await loadDashboard();
} catch (error) {
  Sentry.captureException(error, {
    tags: { screen: 'dashboard' },
    extra: { widget: 'balance-summary' },
  });
}

Ein Brotkrumenpfad kann oft der Unterschied zwischen „Der Benutzer sagt, dass die App eingefroren ist“ und „Die App ist nach dem Öffnen des Dashboards, dem Starten der Synchronisierung und dem erneuten Versuch eines veralteten Anforderung fehlgeschlagen“ sein.

Wenn benutzerdefinierte Instrumentierung schief geht, geht es meistens schief, indem es zu laut ist. Fassen Sie nicht jeden Tastendruck im App für immer ein. Fassen Sie Grenzen, Zustandsübergänge und wichtige Operationen ein, wenn Sie debuggen. Genug Kontext, um das Ereignis zu erklären. Nicht genug, um es zu ertränken.

Überprüfen und Fehlerbeheben Ihrer Integration

You sollten Sentry vor der Veröffentlichung, nach Änderungen im Build-Pipeline und nach SDK-Upgrades überprüfen. „Es funktionierte Monate her“ ist kein aussagekräftiger Test.

Der sauberste Weg ist es, kontrollierte Fehler für beide JavaScript- und native-Pfade auszulösen und dann zu überprüfen, wie sie in Sentry landen.

Sichere Testereignisse auslösen

Für einen JavaScript-Fehler fügen Sie einen temporären Button in einer nicht-produktiven Anzeige hinzu:

<Button
  title="Trigger JS Error"
  onPress={() => {
    throw new Error('Test JavaScript Sentry error');
  }}
/>

Für einen erfassten Ausnahmefall, der das App nicht abstürzen wird:

<Button
  title="Capture Exception"
  onPress={() => {
    Sentry.captureException(new Error('Handled Sentry test error'));
  }}
/>

Native-Crash-Testing sollte sorgfältig und nur in der Entwicklung oder in kontrollierten QA-Builds durchgeführt werden. Die genauen Hilfsmethoden, die verfügbar sind, können je nach SDK-Version und Plattform-Verkabelung variieren, daher bevorzuge ich die Verwendung der SDK-dokumentierten native-Crash-Test-Utility, wenn sie vorhanden ist, anstatt eigene Crash-Pfade zu erfinden.

Was Sie im Sentry-UI überprüfen sollten

Wenn das Ereignis erscheint, überprüfen Sie mehr als den Titel.

Überprüfen Sie diese Felder:

• Plattform und MechanismusDies hilft, JS-Ausnahmen von native Crashes zu unterscheiden.
• Veröffentlichung und dist. Wenn sie leer oder falsch sind, werden Sourcen und Symbolisierung abdriften.
• Stackrahmen. Lesbare Quellortung sollte für korrekt hochgeladene JavaScript-Maps erscheinen.
• Brotkrumen und Tags. Bestätigen Sie, dass Ihr benutzerdefinierter Kontext eingetroffen ist.
• Umgebung. Stellen Sie sicher, dass sich Entwicklung und Produktionsereignisse nicht in einem einzigen Stream mischen.

Wenn ein natives Ereignis eintritt, aber eine schlechte Symbolisierung hat, ändern Sie nicht weiterhin die App code. Das ist meist ein Problem mit einem Build-Artifact.

Gemeinsame Sentry React Native Problemlösung

Ein letzter Gewohnheit, der sich auszahlt, ist das Halten eines kleinen “Überwachungs-Smoke-Test”-Checklisten in Ihrem Release-Prozess. Auslösen Sie ein JS-Ereignis in der Staging-Umgebung, bestätigen Sie die Release-Werte und überprüfen Sie die Quellorte, bevor Sie ein Build vorantreiben

Die Integration mit Live-Update-Workflows wie Capgo

Live-Updates ändern das Release-Modell. Das Binärdatei im Store bleibt gleich, während die JavaScript-Bundle sich darunter ändert. Wenn Sentry immer noch nur in Bezug auf die ursprüngliche App-Version denkt, werden die Stapelspuren schnell irreführend

Die Lösung besteht darin, die Sentry-Release-Identität dem lebenden Bundle zu folgen, nicht nur dem nativen Binärdatei. Die Übereinstimmung von Release-Identifikatoren mit lebenden BundelnFür Live-Update-Workflows behandeln Sie

und

als Laufzeit-Identifikatoren, die der gelieferten JavaScript-Paket verknüpft sind. Die native App-Version ist immer noch wichtig, aber sie reicht allein nicht aus, sobald sich Bundel unabhängig voneinander ändern können. release Ein praktisches Muster sieht so aus: dist Verwenden Sie die native App-Version als Teil des Basis-Release-Namens.

Fügen Sie die Live-Update-Version oder das Paket-Identifikator hinzu.

• Verwenden Sie
• für kanal- oder build-spezifische Differenzierung, wenn das zu Ihrem Modell passt.
• __CAPGO_KEEP_0__ dist __CAPGO_KEEP_0__
• Laden Sie Quellkarten für jeden lebenden Bundle unter genau diesem Release-Bezeichner hoch.

Beispiel: Wenn Ihre App bei der Startzeit Update-Metadaten lädt, initialisieren Sie Sentry mit Werten, die aus dem derzeit aktiven Bundle abgeleitet werden, und nicht nur aus der statischen Build-Konfiguration.

Sentry.init({
  dsn: Config.SENTRY_DSN,
  release: activeBundle.releaseName,
  dist: activeBundle.channel,
});

Dadurch wird, wenn ein Benutzer bei einem hotfixierten Bundle einen Fehler trifft, Sentry die Frames gegen die Quellkarte für diesen Hotfix auflöst und nicht gegen die ältere Store-Bundle.

Das ist wichtig bei jedem OTA-Workflow. Wenn Sie eine gute Einführung in die beweglichen Teile hinter diesem Liefermodell wünschen, ist diese Erklärung von wie live Updates in Capacitor-Apps eine solide Referenz.

Hier ist der Art von Betriebsansicht, die Teams anstreben, wenn sie Update-Metadaten mit Release-Tracking kombinieren:

Der Hauptfehler, den Sie vermeiden sollten, ist die Wiederholung eines statischen Release-Strings für jeden post-Store-Update. Wenn mehrere Bundles denselben Sentry-Release teilen, wird das Debuggen wieder zu einem Rätsel.

Wenn Ihr Team außerhalb von App-Store-Überprüfungszyklen Fixes verschickt, Capgo ist wertvoll. Es gibt Capacitor-Teams eine strukturierte Möglichkeit, live Updates zu liefern, Zielkanäle anzusteuern, Rollouts zu steuern und sich schnell von schlechten Releases zu erholen. Paaren Sie das mit diszipliniertem Sentry-Release-Namen und Quellkarten-Uploads, und Sie erhalten einen Workflow, bei dem Fehler immer noch auf die genaue code-Version hinweisen, die die Benutzer laufen.