Die Einführung einer neuen Version Ihrer mobilen App in die Produktion ist einer der aufregendsten Teile der App-Entwicklung, kann aber auch einer der stressigsten sein! Ihr Team muss den Überblick über die Versionsaufnahme, neue Fehler und die Auswirkungen dieser Fehler, einen Vergleich mit früheren Versionen und mehr behalten.
Auf dieser Seite werden mehrere von Firebase angebotene Tools zur Überwachung der Daten beschrieben, die Sie benötigen, um bei der Veröffentlichung Ihrer mobilen App sicher zu sein.
Verwenden Sie das Release-Monitoring- Dashboard, um Ihre releasebezogenen Daten zu untersuchen
Das Release Monitoring- Dashboard in der Firebase-Konsole wird von Firebase Crashlytics unterstützt. Es handelt sich um ein einziges Dashboard zur Überwachung Ihrer neuesten Produktionsversion. Das Dashboard wird nahezu in Echtzeit aktualisiert und bietet Ihnen einen allgemeinen Überblick über die wichtigsten Release-Metriken, einschließlich Absturzfreiheitsmetriken, Versionsaufnahme, Vergleiche mit früheren Releases und alle neuen Probleme für das Release.
Dieses neue Dashboard verbessert die Seite „Neueste Version“ in der Konsole. Im Vergleich zu dieser Seite fügt das Release Monitoring- Dashboard mehr Informationen hinzu, zeigt nützliche Daten an, ohne dass Google Analytics erforderlich ist, und lädt schneller.
Funktionen des Dashboards
Berichterstattung in Echtzeit
Alle Diagramme werden nahezu in Echtzeit aktualisiert. Kurz nachdem Sie Ihre neueste Version bereitgestellt haben, können Sie zusehen, wie Benutzer beginnen, sich mit dieser Version zu beschäftigen. Sollte es bei einigen dieser Benutzer zu Abstürzen kommen, erkennen Sie die Auswirkungen sofort anhand absturzfreier Metrikdiagramme .Vergleich und Benchmarking basierend auf früheren Versionen
Sie können die Stabilität Ihrer neuesten Version im Kontext Ihrer vorherigen Versionen anzeigen. Mit dem Dashboard können Sie die Live-Metriken Ihrer neuesten Version und bis zu zwei Ihrer zuvor veröffentlichten Builds vergleichen.Top-Neuheiten
Sie können neue Abstürze für Ihre neueste Version anzeigen, sobald sie eintreffen. In der Tabelle „Top neue Probleme“ können Sie die Auswirkungen der zuerst in Ihrer neuesten Version erkannten Probleme überwachen und so schnell eine Entscheidung darüber treffen, ob die Version angehalten oder zurückgesetzt werden soll.
Anforderungen an das Dashboard
Gehen Sie wie folgt vor, um Ihre neueste Version im Release Monitoring- Dashboard anzuzeigen:
Stellen Sie sicher, dass Ihre App mindestens die folgenden Versionen des Crashlytics SDK verwendet:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+Veröffentlichen Sie eine neue Version der App für die Produktion, damit Sie mit Ihrer neuesten Version über eine ausreichende Anzahl engagierter Benutzer verfügen.
FAQs zum Dashboard
Damit ein Build im Dashboard angezeigt wird, muss er mindestens die folgenden Versionen des Crashlytics SDK verwenden:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+
Beachten Sie, dass diese Versionen des SDK oft als „sitzungsfähige“ SDK-Versionen bezeichnet werden, da sie in der Lage sind, Sitzungsdaten an Crashlytics zu senden, was für viele der neuen Funktionen in Crashlytics, wie das Release Monitoring- Dashboard, erforderlich ist.
Damit ein Build im Dashboard angezeigt wird, muss er alle folgenden Anforderungen erfüllen:
Der Build verwendet mindestens die folgenden Versionen des Crashlytics SDK:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+Der Build hat innerhalb der letzten 3 Tage eine ausreichende Anzahl von Benutzern:
Der Build muss mindestens 500 eindeutige Benutzer haben ODER
Der Build hat mindestens 1 % aller Benutzer und mindestens zwei eindeutige Benutzer.
Das Release-Monitoring- Dashboard soll Sie bei Ihren Produktions-Releases unterstützen, also bei Builds mit einer beträchtlichen Anzahl von Benutzern.
Damit ein Build im Dashboard angezeigt wird, muss er alle folgenden Anforderungen erfüllen:
Der Build verwendet mindestens die folgenden Versionen des Crashlytics SDK:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+Der Build hat innerhalb der letzten 3 Tage eine ausreichende Anzahl von Benutzern:
Der Build muss mindestens 500 eindeutige Benutzer haben ODER
Der Build hat mindestens 1 % aller Benutzer und mindestens zwei eindeutige Benutzer.
(Für Apps, die über Google Play vertrieben werden) Wenn eine App über einen Google Play-Link verfügt, zeigt das Dashboard alle im Play Prod-Track aufgeführten Builds an, auch wenn Crashlytics keine Sitzungsprotokolle erhalten oder aktive Benutzer für diesen Build erkannt hat.
Beachten Sie, dass Sie mindestens zwei Builds veröffentlicht haben müssen, die die oben genannten Anforderungen erfüllen, um Daten im Dashboard für Vergleiche oder den Prozentsatz aktiver Benutzer anzuzeigen.
Zunächst ist es hilfreich, einige der mit dem Diagramm „Aktive Benutzer“ verbundenen Terminologien zu verstehen:
Eine Sitzung ist ein kontinuierlicher Zeitraum, in dem ein Benutzer mit einer Anwendung beschäftigt ist. Eine neue Sitzung beginnt, wenn die App kalt gestartet wird oder die App nach mindestens 30 Minuten im Hintergrund im Vordergrund steht.
Aktive Benutzer für einen bestimmten Build sind die Anzahl der Benutzer, die eine Sitzung mit diesem Build gestartet haben, gruppiert nach Stunde.
Die Gesamtzahl der (aktiven) Benutzer ist die Anzahl der Benutzer, die eine Sitzung in einem beliebigen Build der App gestartet haben, der eine sitzungsfähige SDK-Version verwendet, gruppiert nach Stunde.
Im Diagramm „Aktive Benutzer“ stammen der Prozentsatz und die Anzahl der aktiven Benutzer, die immer im Diagramm angezeigt werden, aus den letzten 60 Minuten (oder, wenn es in den letzten 60 Minuten keine aktiven Benutzer gab, aus dem Zeitraum der letzten Stunde, in dem dies der Fall war). Daten haben). Im Beispiel-Screenshot gab es beispielsweise in den letzten 60 Minuten 90 aktive Benutzer für den Build 6.0.0 (600) , was 22,1 % der gesamten (aktiven) Benutzer der App ausmacht.
Wenn Sie mit der Maus über die Linien im Diagramm „Aktive Benutzer“ fahren, wird der Prozentsatz der aktiven Benutzer aus der Anzahl der aktiven Benutzer für den Stundenzeitraum berechnet, über den Sie mit der Maus fahren.
Beachten Sie, dass Sie zum Anzeigen des Prozentsatzes der aktiven Benutzer mindestens zwei Builds veröffentlicht haben müssen, die die in der FAQ „Welche Builds können im Release Monitoring- Dashboard angezeigt werden?“ beschriebenen Anforderungen erfüllen. .
Der Prozentsatz der aktiven Benutzer basiert auf empfangenen Sitzungsdaten und nicht auf anderen Daten (wie Google Play-Daten oder Absturzberichten).
Wenn Sie Ihre App zum ersten Mal mit einer kompatiblen Crashlytics SDK-Version veröffentlichen, verfügt Crashlytics über keine früheren Sitzungsdaten zum Vergleich.
Richten Sie Benachrichtigungen ein
Mehrere Firebase-Produkte, einschließlich Crashlytics, können aus verschiedenen produktspezifischen Gründen Warnungen senden. Um Benachrichtigungen zu erhalten , müssen Sie über die erforderlichen Berechtigungen verfügen.
Um die Stabilität Ihrer neuesten Version zu überwachen, können Sie Warnungen sowohl von Performance Monitoring als auch von Crashlytics einrichten. Speziell für Crashlytics können Sie die folgenden Benachrichtigungen einrichten:
Verwenden Sie Geschwindigkeitswarnungen , um Ihr Team zu benachrichtigen, wenn ein einzelnes Problem in Ihrer App einen von Ihnen in der Firebase-Konsole definierten Schwellenwert überschreitet.
Senden Sie Benachrichtigungen über neue oder zurückgegangene Probleme an Ihren bevorzugten Benachrichtigungskanal:
Verwenden Sie die in der Firebase-Konsole konfigurierten Alarmintegrationen für Jira , Slack und PagerDuty .
Richten Sie mithilfe von Cloud Functions for Firebase erweiterte Benachrichtigungen für Drittanbieterdienste ein.
Stellen Sie vor dem Loslassen eine reibungslose Freigabe sicher
Bevor Sie Ihre neueste Version veröffentlichen, sollten Sie die Nutzung einiger der folgenden Dienste und Funktionen in Betracht ziehen, um eine reibungslose Veröffentlichung sicherzustellen.
Nutzen Sie Testdienste vor der Veröffentlichung
Firebase bietet zwei Produkte an, die beim Testen vor der Veröffentlichung helfen können: Test Lab und App Distribution. Beide Dienste können in Ihre CI/CD-Abläufe integriert werden.
Firebase Test Lab ist eine cloudbasierte App-Testinfrastruktur, mit der Sie Ihre App auf einer Reihe von Geräten und Konfigurationen testen können, sodass Sie frühzeitig ein Verständnis dafür erhalten, wie sie sich in den Händen von Live-Benutzern verhält.
Und wenn Sie bereit sind, Ihren neuesten Build in die Hände vertrauenswürdiger menschlicher Tester zu legen, verwenden Sie Firebase App Distribution . Sie können sowohl Ihre Apple-Plattform als auch Ihre Android-Vorabversionen vom selben Ort aus verwalten.
Nutzen Sie Rollout- und begrenzte Testdienste
Verwenden Sie Firebase Remote Config , um neue Funktionen mit einem prozentualen Rollout-Mechanismus zu starten oder diese Funktionen in einer begrenzten Testgruppe zu testen.
Firebase bietet auch A/B-Tests an, damit Sie Änderungen an der Benutzeroberfläche, Funktionen oder Engagement-Kampagnen Ihrer App testen können, um zu sehen, wie sie sich auf Ihre wichtigsten Kennzahlen (wie Umsatz und Kundenbindung) auswirken, bevor Sie sie umfassend einführen.
,Die Einführung einer neuen Version Ihrer mobilen App in die Produktion ist einer der aufregendsten Teile der App-Entwicklung, kann aber auch einer der stressigsten sein! Ihr Team muss den Überblick über die Versionsaufnahme, neue Fehler und die Auswirkungen dieser Fehler, einen Vergleich mit früheren Versionen und mehr behalten.
Auf dieser Seite werden mehrere von Firebase angebotene Tools zur Überwachung der Daten beschrieben, die Sie benötigen, um bei der Veröffentlichung Ihrer mobilen App sicher zu sein.
Verwenden Sie das Release-Monitoring- Dashboard, um Ihre releasebezogenen Daten zu untersuchen
Das Release Monitoring- Dashboard in der Firebase-Konsole wird von Firebase Crashlytics unterstützt. Es handelt sich um ein einziges Dashboard zur Überwachung Ihrer neuesten Produktionsversion. Das Dashboard wird nahezu in Echtzeit aktualisiert und bietet Ihnen einen allgemeinen Überblick über die wichtigsten Release-Metriken, einschließlich Absturzfreiheitsmetriken, Versionsaufnahme, Vergleiche mit früheren Releases und alle neuen Probleme für das Release.
Dieses neue Dashboard verbessert die Seite „Neueste Version“ in der Konsole. Im Vergleich zu dieser Seite fügt das Release Monitoring- Dashboard mehr Informationen hinzu, zeigt nützliche Daten an, ohne dass Google Analytics erforderlich ist, und lädt schneller.
Funktionen des Dashboards
Berichterstattung in Echtzeit
Alle Diagramme werden nahezu in Echtzeit aktualisiert. Kurz nachdem Sie Ihre neueste Version bereitgestellt haben, können Sie zusehen, wie Benutzer beginnen, sich mit dieser Version zu beschäftigen. Sollte es bei einigen dieser Benutzer zu Abstürzen kommen, erkennen Sie die Auswirkungen sofort anhand absturzfreier Metrikdiagramme .Vergleich und Benchmarking basierend auf früheren Versionen
Sie können die Stabilität Ihrer neuesten Version im Kontext Ihrer vorherigen Versionen anzeigen. Mit dem Dashboard können Sie die Live-Metriken Ihrer neuesten Version und bis zu zwei Ihrer zuvor veröffentlichten Builds vergleichen.Top-Neuheiten
Sie können neue Abstürze für Ihre neueste Version anzeigen, sobald sie eintreffen. In der Tabelle „Top neue Probleme“ können Sie die Auswirkungen der zuerst in Ihrer neuesten Version erkannten Probleme überwachen und so schnell eine Entscheidung darüber treffen, ob die Version angehalten oder zurückgesetzt werden soll.
Anforderungen an das Dashboard
Gehen Sie wie folgt vor, um Ihre neueste Version im Release Monitoring- Dashboard anzuzeigen:
Stellen Sie sicher, dass Ihre App mindestens die folgenden Versionen des Crashlytics SDK verwendet:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+Veröffentlichen Sie eine neue Version der App für die Produktion, damit Sie mit Ihrer neuesten Version über eine ausreichende Anzahl engagierter Benutzer verfügen.
FAQs zum Dashboard
Damit ein Build im Dashboard angezeigt wird, muss er mindestens die folgenden Versionen des Crashlytics SDK verwenden:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+
Beachten Sie, dass diese Versionen des SDK oft als „sitzungsfähige“ SDK-Versionen bezeichnet werden, da sie in der Lage sind, Sitzungsdaten an Crashlytics zu senden, was für viele der neuen Funktionen in Crashlytics erforderlich ist, wie z. B. das Release Monitoring- Dashboard.
Damit ein Build im Dashboard angezeigt wird, muss er alle folgenden Anforderungen erfüllen:
Der Build verwendet mindestens die folgenden Versionen des Crashlytics SDK:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+Der Build hat innerhalb der letzten 3 Tage eine ausreichende Anzahl von Benutzern:
Der Build muss mindestens 500 eindeutige Benutzer haben ODER
Der Build hat mindestens 1 % aller Benutzer und mindestens zwei eindeutige Benutzer.
Das Release-Monitoring- Dashboard soll Sie bei Ihren Produktions-Releases unterstützen, also bei Builds mit einer beträchtlichen Anzahl von Benutzern.
Damit ein Build im Dashboard angezeigt wird, muss er alle folgenden Anforderungen erfüllen:
Der Build verwendet mindestens die folgenden Versionen des Crashlytics SDK:
Apple-Plattformen: v10.8.0+ | Android: v18.6.0+ (BoM v32.6.0+) | Flutter: v3.4.5+ | Einheit: 11.7.0+Der Build hat innerhalb der letzten 3 Tage eine ausreichende Anzahl von Benutzern:
Der Build muss mindestens 500 eindeutige Benutzer haben ODER
Der Build hat mindestens 1 % aller Benutzer und mindestens zwei eindeutige Benutzer.
(Für Apps, die über Google Play vertrieben werden) Wenn eine App über einen Google Play-Link verfügt, zeigt das Dashboard alle im Play Prod-Track aufgeführten Builds an, auch wenn Crashlytics keine Sitzungsprotokolle erhalten oder aktive Benutzer für diesen Build erkannt hat.
Beachten Sie, dass Sie mindestens zwei Builds veröffentlicht haben müssen, die die oben genannten Anforderungen erfüllen, um Daten im Dashboard für Vergleiche oder den Prozentsatz aktiver Benutzer anzuzeigen.
Zunächst ist es hilfreich, einige der mit dem Diagramm „Aktive Benutzer“ verbundenen Terminologien zu verstehen:
Eine Sitzung ist ein kontinuierlicher Zeitraum, in dem ein Benutzer mit einer Anwendung beschäftigt ist. Eine neue Sitzung beginnt, wenn die App kalt gestartet wird oder die App nach mindestens 30 Minuten im Hintergrund im Vordergrund steht.
Aktive Benutzer für einen bestimmten Build sind die Anzahl der Benutzer, die eine Sitzung mit diesem Build gestartet haben, gruppiert nach Stunde.
Die Gesamtzahl der (aktiven) Benutzer ist die Anzahl der Benutzer, die eine Sitzung in einem beliebigen Build der App gestartet haben, der eine sitzungsfähige SDK-Version verwendet, gruppiert nach Stunde.
Im Diagramm „Aktive Benutzer“ stammen der Prozentsatz und die Anzahl der aktiven Benutzer, die immer im Diagramm angezeigt werden, aus den letzten 60 Minuten (oder, wenn es in den letzten 60 Minuten keine aktiven Benutzer gab, aus dem Zeitraum der letzten Stunde, in dem dies der Fall war). Daten haben). Im Beispiel-Screenshot gab es beispielsweise in den letzten 60 Minuten 90 aktive Benutzer für den Build 6.0.0 (600) , was 22,1 % der gesamten (aktiven) Benutzer der App ausmacht.
Wenn Sie mit der Maus über die Linien im Diagramm „Aktive Benutzer“ fahren, wird der Prozentsatz der aktiven Benutzer aus der Anzahl der aktiven Benutzer für den Stundenzeitraum berechnet, über den Sie mit der Maus fahren.
Beachten Sie, dass Sie zum Anzeigen des Prozentsatzes der aktiven Benutzer mindestens zwei Builds veröffentlicht haben müssen, die die in der FAQ „Welche Builds können im Release Monitoring- Dashboard angezeigt werden?“ beschriebenen Anforderungen erfüllen. .
Der Prozentsatz der aktiven Benutzer basiert auf empfangenen Sitzungsdaten und nicht auf anderen Daten (wie Google Play-Daten oder Absturzberichten).
Wenn Sie Ihre App zum ersten Mal mit einer kompatiblen Crashlytics SDK-Version veröffentlichen, verfügt Crashlytics über keine früheren Sitzungsdaten zum Vergleich.
Richten Sie Benachrichtigungen ein
Mehrere Firebase-Produkte, einschließlich Crashlytics, können aus verschiedenen produktspezifischen Gründen Warnungen senden. Um Benachrichtigungen zu erhalten , müssen Sie über die erforderlichen Berechtigungen verfügen.
Um die Stabilität Ihrer neuesten Version zu überwachen, können Sie Warnungen sowohl von Performance Monitoring als auch von Crashlytics einrichten. Speziell für Crashlytics können Sie die folgenden Benachrichtigungen einrichten:
Verwenden Sie Geschwindigkeitswarnungen , um Ihr Team zu benachrichtigen, wenn ein einzelnes Problem in Ihrer App einen von Ihnen in der Firebase-Konsole definierten Schwellenwert überschreitet.
Senden Sie Benachrichtigungen über neue oder zurückgegangene Probleme an Ihren bevorzugten Benachrichtigungskanal:
Verwenden Sie die in der Firebase-Konsole konfigurierten Alarmintegrationen für Jira , Slack und PagerDuty .
Richten Sie mithilfe von Cloud Functions for Firebase erweiterte Benachrichtigungen für Drittanbieterdienste ein.
Stellen Sie vor dem Loslassen eine reibungslose Freigabe sicher
Bevor Sie Ihre neueste Version veröffentlichen, sollten Sie die Nutzung einiger der folgenden Dienste und Funktionen in Betracht ziehen, um eine reibungslose Veröffentlichung sicherzustellen.
Nutzen Sie Testdienste vor der Veröffentlichung
Firebase bietet zwei Produkte an, die beim Testen vor der Veröffentlichung helfen können: Test Lab und App Distribution. Beide Dienste können in Ihre CI/CD-Abläufe integriert werden.
Firebase Test Lab ist eine cloudbasierte App-Testinfrastruktur, mit der Sie Ihre App auf einer Reihe von Geräten und Konfigurationen testen können, sodass Sie frühzeitig ein Verständnis dafür erhalten, wie sie sich in den Händen von Live-Benutzern verhält.
Und wenn Sie bereit sind, Ihren neuesten Build in die Hände vertrauenswürdiger menschlicher Tester zu legen, verwenden Sie Firebase App Distribution . Sie können sowohl Ihre Apple-Plattform als auch Ihre Android-Vorabversionen vom selben Ort aus verwalten.
Nutzen Sie Rollout- und begrenzte Testdienste
Verwenden Sie Firebase Remote Config , um neue Funktionen mit einem prozentualen Rollout-Mechanismus zu starten oder diese Funktionen in einer begrenzten Testgruppe zu testen.
Firebase bietet auch A/B-Tests an, damit Sie Änderungen an der Benutzeroberfläche, Funktionen oder Engagement-Kampagnen Ihrer App testen können, um zu sehen, wie sie sich auf Ihre wichtigsten Kennzahlen (wie Umsatz und Kundenbindung) auswirken, bevor Sie sie umfassend einführen.