Le déploiement d’une nouvelle version de votre application mobile en production est l’une des parties les plus passionnantes du développement d’applications, mais cela peut aussi être l’une des plus stressantes ! Votre équipe doit suivre l'adoption des versions, les nouveaux bogues et leur impact, une comparaison avec les versions précédentes, et bien plus encore.
Cette page décrit plusieurs outils proposés par Firebase pour surveiller les données dont vous avez besoin pour avoir confiance en la sortie de votre application mobile.
Utilisez le tableau de bord Surveillance des versions pour explorer vos données liées aux versions
Le tableau de bord Release Monitoring de la console Firebase est alimenté par Firebase Crashlytics. Il s'agit d'un tableau de bord unique pour surveiller votre version de production la plus récente. Le tableau de bord est mis à jour presque en temps réel et vous offre une vue d'ensemble des métriques de version les plus importantes, notamment les métriques sans crash, l'adoption des versions, les comparaisons avec les versions précédentes et tout nouveau problème pour la version.
Ce nouveau tableau de bord améliore la page Dernière version de la console. Par rapport à cette page, le tableau de bord Release Monitoring ajoute plus d'informations, affiche des données utiles sans avoir besoin de Google Analytics et se charge plus rapidement.
Caractéristiques du tableau de bord
Rapports en temps réel
Tous les graphiques sont mis à jour presque en temps réel. Peu de temps après avoir déployé votre dernière version, vous pouvez voir les utilisateurs commencer à interagir avec cette version. Si certains de ces utilisateurs subissent des plantages, vous connaîtrez immédiatement l'impact grâce à des graphiques de métriques sans plantage .Comparaison et analyse comparative basées sur les versions précédentes
Vous pouvez afficher la stabilité de votre dernière version dans le contexte de vos versions précédentes. Le tableau de bord vous permet de comparer les métriques en direct de votre dernière version et de jusqu'à deux de vos versions précédemment publiées.Principaux nouveaux numéros
Vous pouvez afficher les nouveaux plantages de votre dernière version dès leur arrivée. Dans le tableau Principaux nouveaux problèmes , vous pouvez surveiller l'impact des problèmes détectés pour la première fois dans votre dernière version, ce qui vous permet de prendre rapidement une décision quant à l'arrêt ou à l'annulation de la version.
Exigences pour le tableau de bord
Pour afficher votre dernière version dans le tableau de bord Surveillance des versions , procédez comme suit :
Assurez-vous que votre application utilise au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+Publiez une nouvelle version de l'application en production afin d'avoir un nombre suffisant d'utilisateurs engagés avec votre dernière version .
FAQ sur le tableau de bord
Pour qu'un build apparaisse sur le tableau de bord, il doit utiliser au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+
Notez que ces versions du SDK sont souvent appelées versions du SDK « compatibles avec les sessions », car elles sont capables d'envoyer des données de sessions à Crashlytics, ce qui est requis pour de nombreuses nouvelles fonctionnalités de Crashlytics, comme le tableau de bord de surveillance des versions .
Pour qu'une build apparaisse sur le tableau de bord, elle doit répondre à toutes les exigences suivantes :
La build utilise au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+Le build a un nombre suffisant d'utilisateurs au cours des 3 derniers jours :
La build doit avoir au moins 500 utilisateurs uniques OU
La build compte au moins 1 % du total des utilisateurs et compte au moins 2 utilisateurs uniques.
Le tableau de bord Release Monitoring a pour objectif de vous aider avec vos releases de production, c'est-à-dire les builds qui comptent un nombre important d'utilisateurs.
Pour qu'une build apparaisse sur le tableau de bord, elle doit répondre à toutes les exigences suivantes :
La build utilise au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+Le build a un nombre suffisant d'utilisateurs au cours des 3 derniers jours :
La build doit avoir au moins 500 utilisateurs uniques OU
La build compte au moins 1 % du total des utilisateurs et compte au moins 2 utilisateurs uniques.
(Pour les applications distribuées via Google Play) Si une application dispose d'un lien Google Play , le tableau de bord affiche toutes les builds répertoriées dans la piste Play Prod, même si Crashlytics n'a reçu aucun journal de session ni détecté d'utilisateurs actifs pour cette build.
Notez que pour afficher les données dans le tableau de bord à des fins de comparaison ou pour le pourcentage d'utilisateurs actifs, vous devez avoir publié au moins deux versions répondant aux exigences précédentes.
Tout d’abord, il est utile de comprendre une partie de la terminologie impliquée dans le graphique des utilisateurs actifs :
Une session est une période continue pendant laquelle un utilisateur est engagé avec une application. Une nouvelle session démarre lorsque l'application est démarrée à froid ou lorsque l'application est mise en premier plan après au moins 30 minutes de mise en arrière-plan.
Les utilisateurs actifs pour une build spécifique correspondent au nombre d'utilisateurs qui ont démarré une session à l'aide de cette build, regroupés par heure.
Le nombre total d'utilisateurs (actifs) correspond au nombre d'utilisateurs qui ont démarré une session dans n'importe quelle version de l'application qui utilise une version du SDK prenant en charge les sessions , regroupés par heure.
Dans le graphique Utilisateurs actifs , la valeur en pourcentage et le nombre d'utilisateurs actifs toujours affichés sur le graphique correspondent aux 60 dernières minutes (ou s'il n'y a pas eu d'utilisateurs actifs au cours des 60 dernières minutes, à la période d'une heure écoulée). avoir des données). Par exemple, dans l'exemple de capture d'écran, il y avait 90 utilisateurs actifs pour la version 6.0.0 (600) au cours des 60 dernières minutes, ce qui représente 22,1 % du total des utilisateurs (actifs) de l'application.
Lorsque vous maintenez la souris sur les lignes du graphique Utilisateurs actifs , le pourcentage d'utilisateurs actifs est calculé à partir du nombre d'utilisateurs actifs pour la période horaire survolée.
Notez que pour voir le pourcentage d'utilisateurs actifs, vous devez avoir publié au moins deux builds répondant aux exigences décrites dans la FAQ « Quelles builds peuvent être visualisées sur le tableau de bord de surveillance des versions ? .
Le pourcentage d'utilisateurs actifs est basé sur les données de session reçues et non sur d'autres données (telles que les données Google Play ou les rapports d'erreur).
Si c'est la première fois que vous publiez votre application avec une version compatible du SDK Crashlytics , Crashlytics n'a aucune donnée de session précédente à comparer.
Configurer des alertes
Plusieurs produits Firebase, dont Crashlytics, peuvent envoyer des alertes pour diverses raisons spécifiques au produit. Afin de recevoir des alertes , vous devez disposer des autorisations requises.
Pour surveiller la stabilité de votre dernière version, vous pouvez configurer des alertes à partir de Performance Monitoring et de Crashlytics. Pour Crashlytics spécifiquement, vous pouvez configurer les alertes suivantes :
Utilisez des alertes de vélocité pour avertir votre équipe si un problème individuel dans votre application dépasse un seuil que vous définissez dans la console Firebase.
Envoyez des alertes sur les problèmes nouveaux ou régressés à votre canal de notification préféré :
Utilisez les intégrations d'alertes configurées sur la console Firebase pour Jira , Slack et PagerDuty .
Configurez des alertes avancées pour les services tiers à l'aide de Cloud Functions pour Firebase.
Assurez une libération en douceur avant de libérer
Avant de publier votre dernière version, pensez à utiliser certains des services et fonctionnalités suivants pour garantir une publication fluide.
Utiliser les services de tests préliminaires
Firebase propose deux produits qui peuvent faciliter les tests préliminaires : Test Lab et App Distribution. Ces deux services peuvent être intégrés à vos flux CI/CD.
Firebase Test Lab est une infrastructure de test d'applications basée sur le cloud qui vous permet de tester votre application sur une gamme d'appareils et de configurations, afin que vous puissiez avoir une première compréhension de ses performances entre les mains d'utilisateurs réels.
Et lorsque vous êtes prêt à confier votre dernière version à des testeurs humains de confiance, utilisez Firebase App Distribution . Vous pouvez gérer à la fois votre plate-forme Apple et vos distributions préliminaires Android à partir du même endroit.
Utiliser des services de déploiement et de tests limités
Utilisez Firebase Remote Config pour lancer de nouvelles fonctionnalités avec un mécanisme de déploiement en pourcentage ou tester ces fonctionnalités sur un groupe de test limité .
Firebase propose également des tests A/B afin que vous puissiez tester les modifications apportées à l'interface utilisateur, aux fonctionnalités ou aux campagnes d'engagement de votre application pour voir leur impact sur vos indicateurs clés (comme les revenus et la fidélisation) avant de les déployer à grande échelle.
,Le déploiement d’une nouvelle version de votre application mobile en production est l’une des parties les plus passionnantes du développement d’applications, mais cela peut aussi être l’une des plus stressantes ! Votre équipe doit suivre l'adoption des versions, les nouveaux bogues et leur impact, une comparaison avec les versions précédentes, et bien plus encore.
Cette page décrit plusieurs outils proposés par Firebase pour surveiller les données dont vous avez besoin pour avoir confiance en la sortie de votre application mobile.
Utilisez le tableau de bord Surveillance des versions pour explorer vos données liées aux versions
Le tableau de bord Release Monitoring de la console Firebase est alimenté par Firebase Crashlytics. Il s'agit d'un tableau de bord unique pour surveiller votre version de production la plus récente. Le tableau de bord est mis à jour presque en temps réel et vous offre une vue générale des métriques de version les plus importantes, notamment les métriques sans crash, l'adoption des versions, les comparaisons avec les versions précédentes et tout nouveau problème pour la version.
Ce nouveau tableau de bord améliore la page Dernière version de la console. Par rapport à cette page, le tableau de bord Release Monitoring ajoute plus d'informations, affiche des données utiles sans avoir besoin de Google Analytics et se charge plus rapidement.
Caractéristiques du tableau de bord
Rapports en temps réel
Tous les graphiques sont mis à jour presque en temps réel. Peu de temps après avoir déployé votre dernière version, vous pouvez voir les utilisateurs commencer à interagir avec cette version. Si certains de ces utilisateurs subissent des plantages, vous connaîtrez immédiatement l'impact grâce à des graphiques de métriques sans plantage .Comparaison et analyse comparative basées sur les versions précédentes
Vous pouvez afficher la stabilité de votre dernière version dans le contexte de vos versions précédentes. Le tableau de bord vous permet de comparer les métriques en direct de votre dernière version et de jusqu'à deux de vos versions précédemment publiées.Principaux nouveaux numéros
Vous pouvez afficher les nouveaux plantages de votre dernière version dès leur arrivée. Dans le tableau Principaux nouveaux problèmes , vous pouvez surveiller l'impact des problèmes détectés pour la première fois dans votre dernière version, ce qui vous permet de prendre rapidement une décision quant à l'arrêt ou à l'annulation de la version.
Exigences pour le tableau de bord
Pour afficher votre dernière version dans le tableau de bord Surveillance des versions , procédez comme suit :
Assurez-vous que votre application utilise au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+Publiez une nouvelle version de l'application en production afin d'avoir un nombre suffisant d'utilisateurs engagés avec votre dernière version .
FAQ sur le tableau de bord
Pour qu'un build apparaisse sur le tableau de bord, il doit utiliser au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+
Notez que ces versions du SDK sont souvent appelées versions du SDK « compatibles avec les sessions », car elles sont capables d'envoyer des données de sessions à Crashlytics, ce qui est requis pour de nombreuses nouvelles fonctionnalités de Crashlytics, comme le tableau de bord de surveillance des versions .
Pour qu'une build apparaisse sur le tableau de bord, elle doit répondre à toutes les exigences suivantes :
La build utilise au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+Le build a un nombre suffisant d'utilisateurs au cours des 3 derniers jours :
La build doit avoir au moins 500 utilisateurs uniques OU
La build compte au moins 1 % du total des utilisateurs et compte au moins 2 utilisateurs uniques.
Le tableau de bord Release Monitoring a pour objectif de vous aider avec vos releases de production, c'est-à-dire les builds qui comptent un nombre important d'utilisateurs.
Pour qu'une build apparaisse sur le tableau de bord, elle doit répondre à toutes les exigences suivantes :
La build utilise au minimum les versions suivantes du SDK Crashlytics :
Plateformes Apple : v10.8.0+ | Android : v18.6.0+ (BoM v32.6.0+) | Flutter : v3.4.5+ | Unité : 11.7.0+Le build a un nombre suffisant d'utilisateurs au cours des 3 derniers jours :
La build doit avoir au moins 500 utilisateurs uniques OU
La build compte au moins 1 % du total des utilisateurs et compte au moins 2 utilisateurs uniques.
(Pour les applications distribuées via Google Play) Si une application dispose d'un lien Google Play , le tableau de bord affiche toutes les builds répertoriées dans la piste Play Prod, même si Crashlytics n'a reçu aucun journal de session ni détecté d'utilisateurs actifs pour cette build.
Notez que pour afficher les données dans le tableau de bord à des fins de comparaison ou pour le pourcentage d'utilisateurs actifs, vous devez avoir publié au moins deux versions répondant aux exigences précédentes.
Tout d’abord, il est utile de comprendre une partie de la terminologie impliquée dans le graphique des utilisateurs actifs :
Une session est une période continue pendant laquelle un utilisateur est engagé avec une application. Une nouvelle session démarre lorsque l'application est démarrée à froid ou lorsque l'application est mise en premier plan après au moins 30 minutes de mise en arrière-plan.
Les utilisateurs actifs pour une build spécifique correspondent au nombre d'utilisateurs qui ont démarré une session à l'aide de cette build, regroupés par heure.
Le nombre total d'utilisateurs (actifs) correspond au nombre d'utilisateurs qui ont démarré une session dans n'importe quelle version de l'application qui utilise une version du SDK prenant en charge les sessions , regroupés par heure.
Dans le graphique Utilisateurs actifs , la valeur en pourcentage et le nombre d'utilisateurs actifs toujours affichés sur le graphique correspondent aux 60 dernières minutes (ou s'il n'y a pas eu d'utilisateurs actifs au cours des 60 dernières minutes, à la période d'une heure écoulée). avoir des données). Par exemple, dans l'exemple de capture d'écran, il y avait 90 utilisateurs actifs pour la version 6.0.0 (600) au cours des 60 dernières minutes, ce qui représente 22,1 % du total des utilisateurs (actifs) de l'application.
Lorsque vous maintenez la souris sur les lignes du graphique Utilisateurs actifs , le pourcentage d'utilisateurs actifs est calculé à partir du nombre d'utilisateurs actifs pour la période horaire survolée.
Notez que pour voir le pourcentage d'utilisateurs actifs, vous devez avoir publié au moins deux builds répondant aux exigences décrites dans la FAQ « Quelles builds peuvent être visualisées sur le tableau de bord de surveillance des versions ? .
Le pourcentage d'utilisateurs actifs est basé sur les données de session reçues et non sur d'autres données (telles que les données Google Play ou les rapports d'erreur).
Si c'est la première fois que vous publiez votre application avec une version compatible du SDK Crashlytics , Crashlytics n'a aucune donnée de session précédente à comparer.
Configurer des alertes
Plusieurs produits Firebase, dont Crashlytics, peuvent envoyer des alertes pour diverses raisons spécifiques au produit. Afin de recevoir des alertes , vous devez disposer des autorisations requises.
Pour surveiller la stabilité de votre dernière version, vous pouvez configurer des alertes à partir de Performance Monitoring et de Crashlytics. Pour Crashlytics spécifiquement, vous pouvez configurer les alertes suivantes :
Utilisez des alertes de vélocité pour avertir votre équipe si un problème individuel dans votre application dépasse un seuil que vous définissez dans la console Firebase.
Envoyez des alertes sur les problèmes nouveaux ou régressés à votre canal de notification préféré :
Utilisez les intégrations d'alertes configurées sur la console Firebase pour Jira , Slack et PagerDuty .
Configurez des alertes avancées pour les services tiers à l'aide de Cloud Functions pour Firebase.
Assurez une libération en douceur avant de libérer
Avant de publier votre dernière version, pensez à utiliser certains des services et fonctionnalités suivants pour garantir une publication fluide.
Utiliser les services de tests préliminaires
Firebase propose deux produits qui peuvent faciliter les tests préliminaires : Test Lab et App Distribution. Ces deux services peuvent être intégrés à vos flux CI/CD.
Firebase Test Lab est une infrastructure de test d'applications basée sur le cloud qui vous permet de tester votre application sur une gamme d'appareils et de configurations, afin que vous puissiez avoir une première compréhension de ses performances entre les mains d'utilisateurs réels.
Et lorsque vous êtes prêt à confier votre dernière version à des testeurs humains de confiance, utilisez Firebase App Distribution . Vous pouvez gérer à la fois votre plate-forme Apple et vos distributions préliminaires Android à partir du même endroit.
Utiliser des services de déploiement et de tests limités
Utilisez Firebase Remote Config pour lancer de nouvelles fonctionnalités avec un mécanisme de déploiement en pourcentage ou tester ces fonctionnalités sur un groupe de test limité .
Firebase propose également des tests A/B afin que vous puissiez tester les modifications apportées à l'interface utilisateur, aux fonctionnalités ou aux campagnes d'engagement de votre application pour voir leur impact sur vos indicateurs clés (comme les revenus et la fidélisation) avant de les déployer à grande échelle.