Echtzeit-Anwendungsaktualisierungsanalyse-Tools

Die meisten OTA-Aktualisierungstools können eine neue Bundle senden. Viele weniger zeigen, was nach der Installation durch Benutzer passiert. Diese Anleitung zeigt, wie man diese Signale bewerten und wo Capgo passt für Ionic und Capacitor-Teams.

Inhaltsverzeichnis

• Capgo
• Schritt 2: Definieren Sie die Update-Signale, die Ihr Team beobachten muss
• Schritt 3: Verbinden Sie Echtzeit-Analysen mit Ihrem Update-Workflow
• Schritt 4: Ausrollen über Kanal, Prozentsatz und Benutzer-Risiko
• Schritt 5: Fehler mit Crash- und Leistungskontext diagnostizieren
• Schritt 6: Automatisieren Sie die Bereitstellung und vergleichen Sie die Analyse-Koverage
• Häufig gestellte Fragen
• Zusammenfassung

1. Capgo

Beginnen Sie mit Capgo wenn Ihr Team eine Update-Pfad für die Freigabe, Live-Daten, Rollover und CI/CD benötigt. Capgo ist für Ionic und Capacitor-Apps entwickelt, wo eine Web-Schicht-Paket oft ohne Wartezeit auf einen neuen nativen Build oder eine App-Store-Überprüfung verschickt werden kann.

Capgo bindet die OTA-Versorgung an die Signale, die Sie nach der Veröffentlichung benötigen. Sie können ein Bundle mit einem Befehl veröffentlichen, es hinter einem Kanal platzieren, die Akzeptanz beobachten und dann zurückrollen, wenn die Daten auf eine schlechte Veröffentlichung hinweisen. Ein Kanal ist ein benannter Veröffentlichungsstrecke, wie z.B. Beta, QA oder Produktionsumgebung. Er hält Testnutzer von der Hauptaudienz fern.

Der nützliche Teil ist der Feedbackschleifen. Eine Veröffentlichung sollte vier Fragen schnell beantworten können:

• Hat das Bundle die vorgesehenen Nutzer erreicht?
• Können die Installationen abgeschlossen werden?
• Stiegen nach der Akzeptanz Fehler oder Crashes an?
• Kann die Veröffentlichung ohne Warten auf jede Nutzeraktualisierung gestoppt werden?

Capgo-Funktionen liefern Echtzeit-Analysen, kanalbasierte Rollouts, automatische Rollover und CI/CD-Integration. In der im Vergleich verwendet werdenden Menge war es die einzige Einträge, die in allen vier Feldern mit Ja markiert war. Das macht Capgo zu einem nützlichen Referenzpunkt, wenn Sie andere Werkzeuge bewerten, selbst wenn Ihr App eine kleine Veröffentlichungsteam hat.

Capgo unterstützt auch differenzielle Updates. Der Client erhält die geänderte Teile eines Bundles anstatt das ganze Paket jedes Mal herunterzuladen. Kleine Updates können die Übertragungsarbeit reduzieren, was wichtig ist, wenn Nutzer über schwache Mobilfunknetze oder auf einem lauten Ladengeschäft aktualisieren.

Die Sicherheit sollte noch immer im Entscheidungsprozess berücksichtigt werden. Änderungen über OTA betreffen code, das auf einem Gerät des Benutzers läuft, daher sollten Ihre Teammitglieder definieren, wer veröffentlichen darf, welcher Kanal sie berühren dürfen und wie die Pakete überprüft werden. Capgo bietet Unternehmensgrößen Sicherheitskontrollen für ihren Update-Flow. Wir empfehlen immer noch, die Berechtigungen mit einem nicht-produktiven Kanal zu testen, bevor Sie die Freigabe für die Veröffentlichung gewähren.

Die Preise werden als Abonnement pro Organisation gehandhabt, nicht als einmaliger Einzelhandelskauf oder als Sitzplatzgebühr. Capgo bietet eine 14-tägige kostenlose Testversion, die Ihrem Team Zeit gibt, eine Test-App zu verbinden und den gesamten Release-Weg zu überprüfen, bevor Sie eine Entscheidung treffen.

Für einen genaueren Blick auf die verfügbaren Signale während einer Veröffentlichung siehe diese Real-time-Update-Metriken für Capacitor-Apps. Der richtige Test ist einfach: Veröffentlichen Sie ein harmloses Paket, beobachten Sie seinen Status und üben Sie dann eine Rollover-Praxis.

Schritt 2: Definieren Sie die Update-Signale, die Ihr Team beobachten muss

Der beste Einstieg in die Real-Time-App-Update-Analytics-Setup beginnt mit einer kurzen Liste von Signalen. Öffnen Sie nicht eine Dashboard und sammeln Sie jede Zahl, die es zeigt. Entscheiden Sie sich für die Ereignisse, die eine Veröffentlichungsentscheidung ändern.

Beginnen Sie mit der Update-Lieferung. Verfolgen Sie die Anzahl der Geräte, die für ein Paket bereit waren. Trennen Sie diese Zustände dann auf:

• Eligible, aber nicht kontaktiert.
• Download gestartet.
• Download abgeschlossen.
• Install abgeschlossen.
• Update fehlgeschlagen.
• Rollback ausgelöst.

Diese Zustände verhindern eine häufige Fehlhandlung. Ein hoher Download-Zähler kann gesund aussehen, während die Installationen am letzten Schritt scheitern. Halten Sie den Download-Erfolg und den Installations-Erfolg als separate Maßnahmen fest. Fügen Sie die App-Version, Betriebssystem, Geräte-Typ, Kanal und Bundle-ID zu jedem Ereignis hinzu.

Als Nächstes markieren Sie die Signale, die den Nutzer-Einfluss zeigen. Eine Crash-freie Nutzer-Rate zeigt Ihnen, wie viele Nutzer in einem bestimmten Zeitraum eine Crash vermeiden konnten. Eine Crash-freie Sitzung-Rate untersucht Sitzungen anstatt. Sie beantworten unterschiedliche Fragen, also sollten Sie sie nicht in eine einzige Bewertung zusammenfassen.

Die Retention benötigt eine Cohort-Ansicht. Gruppieren Sie die Nutzer nach dem Datum oder der Veröffentlichung, an der sie das Bundle zum ersten Mal installierten, und vergleichen Sie die Aktivität am ersten Tag, am siebten Tag oder am dreißigsten Tag. Die aggregierte Retention kann eine Abnahme verbergen, wenn neue Installationen zunehmen. Die Cohort-Verfolgung gibt einen kläreren Überblick als eine verschmolzene Gesamtzahl; siehe die mobile App-Analytics-Metriken.

Verwenden Sie Geschäftsevents mit Vorsicht. Eine Veröffentlichung kann ohne Crash ausgelöst werden, aber dennoch die Registrierung oder den Kauf brechen. Verfolgen Sie den Schritt im Ablauf, der für Ihre App wichtig ist. Für eine Feldservice-App könnte das das Öffnen eines Auftrags sein. Für eine bezahlte App könnte es das Abschließen eines Upgrade sein.

Halten Sie die erste Dashboard klein. Wir empfehlen eine Veröffentlichungs-Ansicht mit diesen Gruppen:

• Zustellung: berechtigte Geräte, Downloads, Installationen und Fehlschläge.
• Qualität: Benutzer ohne Fehler, Fehlerquote, Startzeit und Einfrieren.
• Aufnahmegrade: aktive Geräte nach Paket und Kanal.
• Produkt: eine oder zwei Ereignisse, die mit dem Ziel der Veröffentlichung verbunden sind.

Setzen Sie einen Ausgangspunkt vor der Rollout. Verwenden Sie die aktuelle Produktionsversion als Vergleichspunkt. Wenn die neue Version eine höhere Fehlerquote aufweist, benötigen Sie einen Referenzpunkt, der Ihnen sagt, ob der Wechsel neu oder normal ist.

Hauptergebnis: Ein Release-Dashboard sollte zu einer Aktion führen, wie z.B. fortfahren, pausieren, untersuchen oder zurückrollen.

Setzen Sie keine Warnschwellen aus einem allgemeinen Benchmark. Ein Reise-App hat ein anderes Nutzungsverhalten als eine Chat-App. Wählen Sie Schwellen aus Ihren eigenen kürzlichen Produktionsdaten und revidieren Sie sie, wenn sich die App oder das Publikum ändert.

Schritt 3: Verbinden Sie Echtzeit-Analysen mit Ihrem Update-Workflow

Echtzeit-Anwendungsaktualisierungsanalysen werden nützlich, wenn sie sich im Release-Path befinden. Ihr CI/CD-Pipeline sollte das Paket bauen, den Commit identifizieren, es in einen sicheren Kanal veröffentlichen und die Release-Metadaten an Ihre Analyseansicht senden.

Beginnen Sie damit, die Veröffentlichung zu benennen. Verwenden Sie eine Paket-ID, die die App-Version mit einem Commit oder einem Build-Record verbindet. Fügen Sie den Release-Eigentümer und einen kurzen Änderungsvermerk hinzu. Dies spart Zeit, wenn eine Warnung einige Stunden später eintritt.

Verbinden Sie dann den CLI. Ein CLI, oder eine Befehlszeilen-Schnittstelle, ermöglicht es einem Skript, denselben Release-Befehl jederzeit auszuführen. Speichern Sie Anmeldeinformationen in Ihrem CI/CD-Sekretmanager. Legen Sie sie nicht in einem Repository ab oder übermitteln Sie sie über einen Protokoll, wo sie kopiert werden können.

Erstellen Sie das Pipeline in Stufen:

1. Laufen Sie Tests für das Weblayer und den nativen Wrapper.
2. Erstellen Sie das signierte Bundle.
3. Veröffentlichen Sie es in einem Testkanal.
4. Warten Sie auf die ersten Gesundheitsprüfungen.
5. Erweitern Sie das Bundle auf eine begrenzte Produktionsgruppe.
6. Pausieren oder zurückrollen, wenn eine Regel fehlschlägt.

Die Pause ist wichtig. Eine Pipeline, die ohne Stoppunkt veröffentlicht, kann eine schlechte Aktualisierung vor der ersten Fehlermeldung verbreiten. Behandeln Sie die Promotion als separaten Befehl, selbst wenn der gleiche Job sie später ausführt.

Capgo unterstützt eine-Befehls-Deployment und CI/CD-Integration, sodass der Aktualisierungsstep neben dem Rest Ihres Release-Werks sitzen kann. Teams können native Builds im selben Prozess halten, während sie Weblayer-Änderungen über einen OTA-Kanal senden. Diese Aufteilung hilft, wenn die Reparatur keine neue native Binärdatei erfordert.

Nutzen Sie einen Webhook oder API-Ereignis, um den Aktualisierungsstatus mit Ihrem Warnsystem zu verbinden. Der Payload sollte den Bundle-Id, den Kanal, die Zielgruppe, den Installationsstatus und den Fehlerkontext enthalten. Wenn Ihr Analytics-System nicht erkennen kann, welcher Release einen Ereignis ausgelöst hat, zeigt es ein Symptom ohne Ursache.

Behalten Sie die erste Automatisierung eng. Automatisieren Sie eine Testkanalveröffentlichung, bevor Sie die Produktionserweiterung automatisieren. Bitten Sie einen Menschen, der nicht am Änderungsvorgang beteiligt war, um die Rollover-Übung durchzuführen. Ein Wiederherstellungsverfahren, das nur sein Autor versteht, ist nicht für eine Nachtveröffentlichung bereit.

Beobachten Sie die erste Phase einer Rollout-Veröffentlichung, bevor Sie sie erweitern. Die genaue Wartezeit hängt von dem Traffic und dem Risiko ab. Eine Zahlungsänderung benötigt eine engeres Auge als eine Kopie-Korrektur.

Für Teams, die den Veröffentlichungsweg um die Versionskontrolle herum bauen, dieser Workflow Kann dabei helfen, die Übergabe zwischen Build, Veröffentlichung, Beobachtung und Wiederherstellung zu kartieren.

Schritt 4: Rollout über Kanal, Prozentsatz und Benutzer-Risiko

Verwenden Sie Kanäle und Prozentsätze, um die Auswirkungen zu begrenzen, während die besten Echtzeit-Analytics-Werkzeuge für die App-Updates Beweise sammeln. Ein Kanal ist die Kontrollschicht. Ein Prozentsatz ist die Größe der Zielgruppe innerhalb dieser Schicht.

Erstellen Sie einen Kanalplan, bevor Sie veröffentlichen. Ein kleines Team könnte beispielsweise verwenden:

• Entwicklung: Interne Builds und lokale Überprüfungen.
• QA: Wiederholbare Geräte- und Fluss-Tests.
• Testphase: Freiwillige Benutzer, die ein gewisses Risiko eingehen.
• Produktion: die Hauptbenutzergruppe.

Halten Sie die Regeln für den Kanal klar. Notieren Sie, wer eine Paketversion promoten kann und welche Überprüfungen zuerst durchgeführt werden müssen. Ein Kanalname sollte dem nächsten Ingenieur sagen, wofür er ist. Vermeiden Sie Bezeichnungen, die nur für denjenigen Sinn ergeben, der sie erstellt hat.

Wählen Sie die erste Gruppe nach Risiko. Inhouse-Benutzer sind nützlich für die Überprüfung einer grundlegenden Veröffentlichung. Sie offenbaren jedoch nicht immer ein regionales Netzwerkproblem oder einen Gerätespezifischen Crash. Wenn Ihre Daten eine Segmentation unterstützen, sollten Sie eine kleine Mischung aus Betriebssystemen und Geräteklassen frühzeitig einbeziehen.

Als Nächstes setzen Sie den Rollout-Prozentsatz. Beginnen Sie mit einer begrenzten Zielgruppe. Überwachen Sie die Lieferung und die Produkt-Signale gemeinsam. Wenn sich die Installationen erhöhen, aber eine wichtige Aktion zurückgeht, unterbrechen Sie den Rollout, auch wenn der Download-Rate in Ordnung aussieht.

Die automatische Rückkehr ändert die Reaktionszeit. Ohne sie muss jemand das Warnsignal sehen, bestätigen, dass die Veröffentlichung es verursacht hat, und einen manuellen Wiederherstellungs-Befehl ausführen. Mit einer definierten Rückkehr-Regel kann das System die Benutzer auf eine bekannte Paketversion zurücksetzen, wenn die Veröffentlichung diese Grenze überschreitet.

Die Rückkehr-Regeln benötigen Sicherheitsgurte. Legen Sie eine Mindestanzahl von Ereignissen fest, damit ein Testgerät nicht einen vollständigen Wiederherstellungsprozess auslöst. Limitieren Sie die Regel auf den betroffenen Kanal oder Paket. Notieren Sie jeden Rückruf mit seinem Auslöser und Besitzer. Ansonsten kann das Team die Veröffentlichung beheben, während der Grund weiterhin unklar bleibt.

Capgo unterstützt kanalbasierte Rollouts und automatische Rückschritte. Diese Kombination ist leicht zu übersehen, wenn Teams Werkzeuge nur nach der Downloadlieferung vergleichen.

Pro-Tipp: Schreiben Sie die Rückschritsregel, bevor Sie veröffentlichen. Wenn das Team während eines Vorfalls den Schwellenwert debattiert, ist der Schwellenwert zu spät.

Verwenden Sie eine Release-Notiz, die angibt, was geändert wurde und was beobachtet werden sollte. „Aktualisieren Sie die Abhängigkeiten“ ist zu vage. „Änderte sich die Offline-Synchronisation nach einem abgeschlossenen Auftragsarbeitsvorgang“ gibt dem auf der Schicht befindlichen Mitarbeiter einen Testpfad.

Wenn die erste Gruppe gesund bleibt, erweitern Sie in kleinen Schritten. Wenn ein Signal sich verschlechtert, stoppen Sie die Promotion zuerst. Dann vergleichen Sie die neue Bundle mit der letzten bekannten guten Version.

Schritt 5: Fehlerdiagnose mit Crash- und Leistungskontext

Analytik kann Ihnen sagen, dass eine OTA-Veröffentlichung fehlschlägt. Crash- und Leistungskontext hilft, warum. Die nützliche Ansicht verbindet die Bundle-ID mit dem betroffenen Benutzer, Gerät, Anwendungsstatus und Ereignisweg.

Beginnen Sie mit dem ersten schlechten Signal. Steigt die Crashrate nach der Installation? Verlangsamt sich der Start? Fällt die Aktualisierung vor dem Laden der Anwendung aus? Jedes Muster deutet auf einen anderen Teil des Releasepfads hin.

• Installationsfehler: Überprüfen Sie die Bundle-Integrität, -Kompatibilität und -Netzwerkbedingungen.
• Startfehler: Überprüfen Sie code , das vor dem ersten Bildschirm läuft.
• Funktionsfehler: Vergleichen Sie den geänderten Workflow mit der Release-Notiz.
• Langsame Bildschirme: Überprüfen Sie neue Arbeit bei der Startseite oder nach der Navigation.
• Einbruch in die Konvertierung: Überprüfen Sie den genauen Schritt im Ablauf, der betroffen ist.

Zerlegen Sie jeden Signalwert nach Kanal und Bundle. Eine globale Durchschnittswert kann einen Crash, der auf einem Release-Track begrenzt ist, verbergen. Fügen Sie nur Geografie hinzu, wenn es hilft, ein Netzwerk- oder Dienstproblem zu isolieren. Zu viele Filter verzögern die erste Reaktion.

Betrachten Sie die Benutzer sowie die Sitzungen. Ein Benutzer kann das App mehrmals öffnen, nachdem ein Update fehlgeschlagen ist. Zählt man nur Sitzungen, kann die Fehlfunktion größer oder kleiner erscheinen als die Anzahl der betroffenen Personen.

Die Leistung benötigt einen Referenzpunkt. Vergleichen Sie die Startzeit und die Ladezeit der wichtigen Bildschirme mit dem vorherigen Bundle. Vergleichen Sie einen neuen Release nicht während eines Verkehrsspitzen mit einem ruhigen älteren Release, es sei denn, Sie markieren diese Differenz.

Die Sitzungs-Wiedergabe kann helfen, wenn die Ereignisdaten sagen “Checkout fehlgeschlagen” aber nicht den Bildschirzustand zeigen. Sie kann einen blockierten Button, einen Loop oder ein Layoutproblem offenlegen, das eine Stack-Trace nicht beschreiben kann. Ereigniszeit von Kann helfen, zu erklären, was ein Benutzer nach dem Auftauchen von Inhalten getan hat. Kann helfen, zu erklären, was ein Benutzer nach dem Auftauchen von Inhalten getan hat.

Behalte die Privatsphäre im Workflow. Entferne Geheimnisse aus den Protokollen. Vermeide das Senden von Zahlungsdaten oder privaten Texten in Ereignis-Eigenschaften. Geben Sie Support-Mitarbeitern den kleinstmöglichen Blick, den sie benötigen, um eine Beschwerde einer Veröffentlichung zuzuordnen.

Stoppen Sie die Ausrollung, sobald Sie eine wahrscheinliche Ursache gefunden haben, bevor Sie sie beheben. Veröffentlichen Sie die Korrektur in einem Testkanal. Wiederholen Sie dann denselben fehlerhaften Weg. Ein Rollback hält die Benutzer von Schaden ab, beweist aber nicht, dass der nächste Bundle sicher ist.

Schlüssigkeitsnahme: Verbinden Sie immer eine Fehlfunktion mit einem bestimmten Bundle, Kanal, Gerätegruppe und Benutzeraktion, bevor Sie die Veröffentlichung ändern.

Teams, die mehr Details benötigen, können den Capgo-Setup für Capgo als Ausgangspunkt für Fehler- und Leistungskontrollen verwenden. performance monitoring setup for Capacitor Vergleichen Sie Werkzeuge nicht nach der Anzahl der Karten auf der Dashboard-Karte, sondern nach den Entscheidungen, die sie unterstützen. Der beste Echtzeit-App-Update-Analytics-Workflow sollte Ihnen helfen, die Adoption zu verfolgen, die Exposition zu pausieren, sicher zurückzurollten und die Veröffentlichung mit CI/CD zu verbinden.

Die folgende Tabelle verwendet die für 12 OTA-Plattformen gesammelten Forschungsfelder. Ein Doppelpunkt bedeutet, dass die Quelldaten keine klare Ja-Antwort für dieses Feld berichteten. Texte, die in einer Herstellerbeschreibung gefunden werden, können nicht als Ja in der extrahierten Feature-Flag-Ausgabe erscheinen, daher betrachten Sie die Tabelle als Screeninghilfe und nicht als vollständige Produktprüfung.

Option

Lebendige Analytik-Signale

Lese die Tabelle, indem du fragst, was während einer schlechten Veröffentlichung passiert. Kann das System den betroffenen Bundle anzeigen? Kann es die nächste Promotion stoppen? Kann es die Benutzer auf die letzte bekannte gute Version zurückkehren lassen? Kann dein Pipeline ohne manuelle Copy-and-Paste-Schritte veröffentlichen?

Die kostenlose Zugriff ist auch ungleichmäßig. Capgo verwendet ein 14-tägiges kostenloses Testangebot, das an das Organisationssubskriptionsmodell gebunden ist. Nutze dieses Testangebot, um einen vollständigen Pfad zu testen, nicht nur das Dashboard. Erstelle, veröffentliche, installiere, beobachte, pause und richte zurück.

Laufe denselben Test gegen jede Plattform unter Überprüfung durch. Nutze ein kleines Capacitor-Anwendungsprogramm. Füge eine harmlose Textänderung hinzu. Sende es an einen Testkanal. Dann simuliere eine fehlgeschlagene Installation oder eine steigende Fehlerquote. Der Gewinner für dein Team ist das Tool, das die Antwort klar macht, ohne ein zweites Betriebsystem hinzuzufügen.

Halten Sie Ihren Pipeline langweilig. Ein vorhersehbarer Befehl und ein sichtbarer Releasezustand schlagen einen cleveren Workflow, den nur ein Ingenieur aufrechterhalten kann.

FAQ

Welche Echtzeit-Analytik für App-Updates gibt es?

Echtzeit-Analytik für App-Updates zeigt, was passiert, wenn Benutzer ein neues App-Paket erhalten und ausführen. Dazu können Downloadzustand, Installationserfolg, Adoption durch Kanal, Fehler, Crashes und Produktereignisse gehören. Für Teams, die Update-Analyse-Tools vergleichen, ist der nützliche Test, ob die Daten schnell genug eintreffen, um eine Rollout-Pause oder eine Wiederherstellung auszulösen.

Welche Signale sollte ich nach einer OTA-Veröffentlichung verfolgen?

Installationserfolg, Update-Fehler, Bundle-Adoption, Crash-freie Benutzer, Startleistung und ein Geschäftsevent, das mit der Änderung zusammenhängt. Die richtigen Signale für Echtzeit-Analytik von App-Updates hängen von Ihrer App ab. Ein Checkout-Release benötigt Daten zum Kauffluss. Ein Offline-Workflow benötigt Synchronisations- und Wiederherstellungsereignisse.

Können Capacitor-Apps Echtzeit-OTA-Analytik verwenden?

Ja, Capacitor-Apps können OTA-Lieferung mit Update- und App-Gesundheitsanalytik kombinieren. Capgo ist für Ionic- und Capacitor-Teams gebaut und verbindet die Lieferung von Paketen mit Kanälen, Rollback und CI/CD. Testen Sie den gesamten Weg mit einer kleinen App vor der Produktion. Bestätigen Sie, dass jedes Ereignis den Paket-Id und den Kanal enthält.

Werden Kanäle für App-Updates relevant?

Kanäle ermöglichen es Ihnen, ein Paket an eine benannte Gruppe vor einer breiteren Veröffentlichung zu senden. Das macht es einfacher, Beta-, QA- oder Produktionsbenutzer separat zu testen. In einem Analytics-Workflow zeigen Kanäle auch, welche Zielgruppe das Problem gesehen hat. Fügen Sie Prozentsatzkontrollen hinzu, wenn Sie eine erweiterte Ausstrahlung in Maßnahmen schrittweise benötigen.

Should automatic rollback be part of an OTA tool?

Ein automatischer Rückruf ist nützlich, wenn eine Veröffentlichung vor einer Person reagiert, Schaden anrichten kann. Legen Sie einen klaren Trigger aufgrund von ausreichenden Ereignissen fest und kehren die betroffenen Benutzer zu einem bekannten guten Paket zurück. Echtzeit-App-Update-Analytics hilft dabei, das Problem zu erkennen, während der Rückruf die Wiederherstellungsaktion bereitstellt. Halten Sie einen manuellen Übertrag für ungewöhnliche Vorfälle bereit.

Zusammenfassung

Wählen Sie Capgo , wenn Ihr Ionic- oder Capacitor -Team lebendige Release-Daten, Kanal-Kontrolle, automatischen Rückruf und CI/CD in einer Update-Workflow benötigt. Starten Sie den 14-tägigen kostenlosen Test mit einer Test-App, veröffentlichen Sie ein harmloses Paket und führen Sie den Rückruf-Drill durch, bevor Sie in die Produktion wechseln.