Pour les applications de production, vous devez configurer un workflow de développement clair, en particulier si plusieurs personnes travaillent sur votre application. Un workflow de développement implique généralement la configuration et la gestion de plusieurs environnements.
Firebase propose différents niveaux de compatibilité pour les workflows des développeurs et les environnements qui les composent. Une fois que vous vous êtes familiarisé avec les termes et les hypothèses du workflow de développement sur cette page, consultez nos bonnes pratiques générales et nos consignes de sécurité générales pour configurer un projet Firebase et vos applications.
À propos des environnements
Dans le développement de logiciels, un environnement correspond à l'ensemble du matériel et des logiciels nécessaires à l'exécution d'une instance d'une application ou d'un système d'applications.
Une série d'environnements permet d'isoler le développement et les tests de logiciels sans impacter les utilisateurs. Comme illustré dans le schéma ci-dessous, les environnements de haut niveau sont considérés comme des environnements de préproduction ou de production. Vous pouvez avoir autant d'environnements de préproduction que nécessaire. Le diagramme décrit également les pratiques et fonctionnalités courantes associées à chaque type d'environnement.
Le processus de progression d'une fonctionnalité ou d'une version dans ces environnements jusqu'à la production est appelé pipeline de déploiement.

Types d'environnements
Un environnement est composé de l'infrastructure sous-jacente dont vous avez besoin pour exécuter et prendre en charge votre application, son code et ses données. Développez chacun des termes suivants pour consulter les descriptions de certains environnements courants, y compris des conseils sur les types de données utilisés dans chaque type d'environnement.
Environnements de développement (dev)
Chaque développeur a besoin d'un environnement de développement, c'est-à-dire d'un espace sécurisé et isolé pour tester les modifications au fur et à mesure de leur création. Idéalement, chaque développeur de votre équipe a accès à son propre environnement de développement. De plus, si l'environnement de développement est une instance locale, un développeur peut effectuer des itérations beaucoup plus rapidement.
Les données d'un environnement de développement sont alimentées par des données qui ressemblent généralement aux données de production, mais ne doivent jamais contenir de données d'utilisateurs réels. Il peut également contenir des données qui ont provoqué des bugs par le passé, comme des chaînes très longues.
Environnements de test et d'assurance qualité
Si vous disposez de tests automatisés, vous avez besoin d'un environnement pour les exécuter et vous devez réinitialiser les données chaque fois que vous créez l'environnement de test.
Si vous disposez d'ingénieurs QA, ils peuvent avoir besoin d'un environnement qu'ils utilisent tous, ou d'environnements individuels pour tester une nouvelle version candidate.
Les données des environnements de test et de contrôle qualité sont alimentées par des données de qualité qui sont généralement représentatives des données produit, ainsi que par des données qui représentent des cas limites et des exemples de données ayant causé des bugs par le passé.
Environnements de préproduction
Pour tester de manière réaliste le fonctionnement d'une version en production, vous avez besoin d'un environnement de préproduction qui imite l'infrastructure de production le plus fidèlement possible. Il est courant d'avoir plusieurs instances de préproduction si vous devez tester des intégrations spécifiques de manière isolée.
Voici les différences courantes entre l'environnement de préproduction et l'environnement de production :
Il se peut que certaines fonctionnalités ou intégrations soient manquantes dans l'environnement de préproduction, ce qui peut entraîner des effets secondaires. Par exemple, l'environnement de préproduction peut être configuré pour ne pas envoyer d'e-mails.
L'environnement de préproduction peut contenir des données anonymisées. Les données peuvent être fictives, mais elles doivent être réalistes. Étant donné que l'environnement de préproduction est un endroit où vous pouvez déboguer les problèmes en toute sécurité, vous pouvez accorder à l'équipe un accès plus large aux données de préproduction qu'aux données de production. Pour protéger la confidentialité des utilisateurs, vous ne devez donc pas utiliser de données utilisateur réelles dans l'environnement de préproduction.
Environnements de production (prod)
Pour chaque application que vous gérez, vous avez besoin d'un seul environnement de production. Il s'agit de l'instance avec laquelle vos utilisateurs interagissent.
Contrairement aux autres environnements où vous pouvez modifier, supprimer et/ou recréer des données, les données de votre environnement de production sont très importantes. La perte ou la modification de vos données de production affectera directement vos utilisateurs.
Dans la console Firebase, nous vous recommandons d'ajouter un tag au projet Firebase associé à votre environnement de production en tant que type d'environnement "production". Ce tag peut vous rappeler, à vous et à vos collaborateurs, que toute modification peut avoir un impact sur vos applications de production associées et leurs données.
Étapes suivantes
Consultez nos bonnes pratiques générales pour configurer des projets Firebase. Ce guide répond aux questions sur la hiérarchie des projets Firebase, l'enregistrement des variantes de votre application et l'architecture mutualisée.
Consultez les consignes de sécurité générales pour différents environnements. Vous voulez vous assurer que chaque environnement et ses données sont sécurisés.
Consultez la checklist de lancement de Firebase.