Les modèles Remote Config sont des ensembles de paramètres et de conditions au format JSON créés pour votre projet Firebase. Remote Config organise les configurations en modèles qui peuvent être créés, mis à jour, gérés par version et annulés.
En fonction de votre architecture, vous pouvez créer et gérer des modèles client, des modèles serveur ou les deux :
Modèles client : diffusez des configurations vers des instances d'application cliente sur les plates-formes Apple, Android, Web, Flutter, Unity et C++. Les modèles client sont compatibles avec les conditions basées sur les audiences Google Analytics, les versions d'application, la plate-forme, la langue de l'appareil, le pays, les centiles d'utilisateurs et les signaux personnalisés.
Modèles de serveur : diffusez des configurations vers des environnements de backend tels que Cloud Run, Cloud Functions for Firebase ou des serveurs conteneurisés à l'aide du Firebase Admin SDK pour Node.js, Python, Go et Java. Les modèles de serveur évaluent les paramètres côté serveur avec une latence quasi nulle à l'aide de signaux personnalisés de serveur et de déploiements à pourcentage aléatoire.
Comparer les modèles client et serveur
Les modèles client et serveur sont gérés indépendamment dans votre projet Firebase. Le tableau suivant vous permet de comprendre les différences entre les modèles client et serveur :
| Fonctionnalité | Modèles de clients | Modèles de serveur |
|---|---|---|
| Environnements cibles | Applications clientes (Apple, Android, Web, Flutter, Unity, C++) | Environnements de serveur (Cloud Run, Cloud Functions for Firebase, GKE, services de backend) |
| SDK compatibles | SDK client Firebase | Firebase Admin SDK (Node.js, Python, Go, Java) |
| Outils de gestion | Console Firebase, CLI Firebase, API REST, Firebase Admin SDK | Console Firebase |
| Emplacement de la console | Paramètres et conditions | Paramètres et conditions |
| Téléchargement des modèles par défaut | Compatible (XML pour Android, PLIST pour iOS, JSON pour le Web) | Non applicable (valeurs par défaut définies dans le code du serveur ou le backend) |
| Guide détaillé | Gérer les modèles de client | Gérer les modèles côté serveur |
Cycle de vie et gestion des versions des modèles
Que vous travailliez avec des modèles client ou serveur, Remote Config fournit un contrôle des versions et une gestion du cycle de vie intégrés :
Création et suivi des versions
Chaque fois que vous mettez à jour des paramètres ou des conditions, Remote Config crée un modèle Remote Config avec une nouvelle version et stocke le modèle précédent en tant que version que vous pouvez récupérer ou restaurer si nécessaire. Les numéros de version sont incrémentés de manière séquentielle à partir de la valeur initiale stockée par Remote Config.
Tous les modèles incluent un champ version contenant des métadonnées sur cette version spécifique, par exemple :
versionNumber: numéro de version séquentiel du modèle.updateTime: code temporel de la publication du modèle.updateUser: adresse e-mail ou identité de l'utilisateur qui a effectué la mise à jour.updateOrigin: comment la modification a été effectuée (par exemple,CONSOLE,REST_APIouADMIN_SDK_NODE).updateType: nature de la modification (par exemple,INCREMENTAL_UPDATEouFORCED_UPDATE).
Limites et conservation des versions
Le nombre total de versions stockées par type de modèle est limité à 300 (300 modèles client et 300 modèles serveur), ce qui inclut les numéros de version stockés pour les modèles supprimés. Si vous publiez plus de 300 versions de modèle par type de modèle pendant la durée de vie d'un projet, les versions les plus anciennes sont supprimées, ce qui permet de conserver un maximum de 300 versions de ce type.
Rollbacks
Vous pouvez revenir à tout moment à n'importe quelle version stockée d'un modèle. Lorsque vous effectuez un rollback, Remote Config crée une version dont le contenu correspond à la version historique sélectionnée. Par exemple, si vous effectuez un rollback de la version 10 à la version 6, la version 11 est créée avec la configuration de la version 6.
Importation et exportation
Vous pouvez télécharger votre modèle actif sous forme de fichier JSON et le publier dans le même projet ou dans un autre projet. Cette fonctionnalité vous permet d'effectuer les actions suivantes :
- Stocker les définitions de modèles dans un système de contrôle de version (comme Git).
- Intégrez les déploiements de configuration aux pipelines CI/CD.
- Promouvoir des configurations d'une étape à l'autre (par exemple, d'un projet de développement ou de préproduction à un projet de production).
- Migrer des configurations entre des projets
Les paramètres et les valeurs de paramètre créés spécifiquement en tant que variantes dans une expérience A/B Testing ne sont pas inclus dans les modèles exportés.
Valeurs par défaut du modèle
Pour les applications clientes, vous pouvez télécharger des fichiers contenant les valeurs par défaut des paramètres au format XML, PLIST ou JSON à intégrer à votre application. Pour obtenir des instructions, consultez Télécharger les valeurs par défaut du modèle Remote Config.
Étapes suivantes
- Modèles de client : découvrez comment gérer, versionner, télécharger et publier des modèles de client dans Gérer les modèles de client et le contrôle des versions de Remote Config.
- Modèles de serveur : découvrez comment gérer, versionner et publier des modèles de serveur dans Gérer les modèles de serveur Remote Config et la gestion des versions.
- Paramètres et conditions : découvrez comment fonctionnent les paramètres et les conditions dans la présentation des paramètres et des conditions Remote Config.
- Automatiser les mises à jour : découvrez comment modifier des modèles de manière programmatique dans Modifier Remote Config de manière programmatique.