Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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 de configurer et de gérer plusieurs environnements.
Firebase offre différents niveaux d'assistance pour les workflows de développement et
les environnements publics. Une fois que vous avez pris connaissance des termes et des hypothèses du workflow de développement sur cette page, consultez nos bonnes pratiques générales et nos consignes générales de sécurité pour configurer un projet Firebase et vos applications.
À propos des environnements
Dans le développement logiciel, un environnement regroupe l'ensemble des composants matériels et logiciels
nécessaires à l'exécution d'une instance
d'une application ou d'un système
applications.
Une série d'environnements assure l'isolation pour le développement et le test de logiciels
sans affecter les utilisateurs. Comme le montre le schéma ci-dessous, les environnements
sont considérés comme étant en préproduction ou en production.
disposent d'autant d'environnements
de préproduction que nécessaire. Le schéma décrit également
des pratiques et des fonctionnalités courantes associées
type d'environnement.
Le processus de progression d'une fonctionnalité ou d'une version à travers 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
pour examiner les descriptions de certains environnements courants, y compris
sur les types de données utilisés dans chaque type d'environnement.
Environnements de développement
Chaque développeur a besoin d'un environnement de développement, un espace sûr 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
à leur propre environnement de développement. De plus, si l'environnement de développement est une instance locale,
un développeur peut itérer
beaucoup plus rapidement.
Les données d'un environnement de développement sont initialisées avec 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 aussi
contiennent des données qui ont causé des bogues dans le passé, comme des chaînes très longues.
Environnements de test et de contrôle qualité
Si vous disposez de tests automatisés, vous avez besoin d'un environnement dans lequel les exécuter
et vous devez réinitialiser les données chaque fois que vous lancez le test
environnement.
Si vous avez des ingénieurs de contrôle qualité,
ils auront peut-être besoin d'un environnement qu'ils utilisent tous
ils peuvent avoir besoin d'environnements
individuels pour tester une nouvelle version candidate.
Dans les environnements de test et de contrôle qualité,
les données sont de bonne qualité
généralement représentatives des données de production, ainsi que des données qui représentent
des cas critiques et des exemples de données
qui ont causé des bugs dans 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
Il est fréquent d'avoir plusieurs instances de préproduction si vous devez tester des
de façon isolée.
Voici les principales différences entre la préproduction et la production:
Il est possible qu'il manque des fonctionnalités ou intégrations qui pourraient entraîner des problèmes
les effets. Par exemple, la préproduction peut être définie pour ne pas envoyer d'e-mail.
La mise en préproduction peut contenir des données anonymisées ; les données peuvent être falsifiées, mais elles doivent être
réaliste. Étant donné que la préproduction permet de déboguer les problèmes en toute sécurité, vous pouvez accorder
aux données de préproduction
que les données de production. Pour protéger les utilisateurs
la confidentialité, vous ne devez pas utiliser
les données utilisateur réelles lors de la préproduction.
Environnements de production (prod)
Pour chaque application que vous gérez, vous n'avez besoin que d'une seule ressource de production
environnement. Il s'agit de l'instance avec laquelle vos utilisateurs interagissent.
Contrairement aux autres environnements dans lesquels 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 des tags au projet Firebase associé
avec votre environnement de production
"production" type d'environnement. Ce tag
peut vous rappeler, à vous et à vos collègues, que tout changement peut affecter vos
les applications de production associées et leurs données.
Étapes suivantes
Consulter nos bonnes pratiques générales
pour configurer des projets Firebase. Ce guide répond aux questions sur Firebase
la hiérarchie des projets, l'enregistrement des variantes de votre application et l'architecture mutualisée.
Consultez les consignes générales de sécurité pour différents environnements. Vous devez vous assurer que chaque environnement et ses
sont sécurisées.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/25 (UTC).
[null,null,["Dernière mise à jour le 2025/07/25 (UTC)."],[],[],null,["For production apps, you need to set up a clear development workflow, especially\nif you have more than one person working on your app. A development workflow\nusually involves setting up and managing multiple environments.\n\nFirebase has varying levels of support for developer workflows and the\nconstituent environments. Once you're familiar with the developer workflow terms\nand assumptions on this page, check out our\n[general best practices](/docs/projects/dev-workflows/general-best-practices)\nand\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\nfor setting up a Firebase project and your apps.\n| **Key Point:** We recommend reading our guides thoroughly, but here's the top takeaway about development workflows: \n| **Firebase recommends using a *separate* Firebase project for *each* environment\n| in your development workflow.**\n\nAbout environments\n\nIn software development, an ***environment*** is all the hardware and software\nthat are required to run an instance of an application or system of\napplications.\n\nA series of environments provides isolation for developing and testing software\nwithout impacting users. As shown in the diagram below, environments at a\nhigh-level are considered either *pre-production* or *production* , and you can\nhave as many pre-production environments as needed. The diagram also describes\ncommon practices and features associated with each\n[type of environment](#types).\n\nThe process of progressing a feature or release through these environments to\nproduction is called a ***deployment pipeline***.\n\nTypes of environments\n\nAn environment is composed of the underlying infrastructure that you need to run\nand support your application, its code, and its data. Expand each of the\nfollowing terms to review descriptions of some common environments, including\ntips on the types of data used in each environment type.\n| **Key Point:** Every app should have at least one *pre-production* environment that's isolated from production data and resources.\n\n\u003cbr /\u003e\n\n**Development (dev) environments**\n\n\u003cbr /\u003e\n\nEvery developer needs a development environment --- a safe, isolated place to test\nchanges as they're being built. Ideally, every developer on your team has access\nto their own dev environment. Also, if the dev environment is a local instance,\na developer can iterate much faster.\n\nThe data in a dev environment is seeded with data that generally resembles the\nproduction data, but should never contain any real users' data. It may also\ncontain data that has caused bugs in the past, like very long strings.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Test and QA environments**\n\n\u003cbr /\u003e\n\nIf you have automated tests, you need an environment in which to run those\ntests, and you need to reset the data each time you spin up the test\nenvironment.\n\nIf you have QA engineers, they may need one environment that they all use, or\nthey may need individual environments to test a new release candidate.\n\nThe data in test and QA environments is seeded with quality data that's\ngenerally representative of the production data, along with data that represents\ncorner cases and examples of data that have caused bugs in the past.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Staging environments**\n\n\u003cbr /\u003e\n\nFor realistic tests of how a release will work in production, you need a staging\nenvironment that mimics production infrastructure as closely as possible. It's\ncommon to have multiple staging instances if you need to test specific\nintegrations in isolation.\n\nHere are common differences between staging and prod:\n\n- Staging may be missing some features or integrations that could cause side\n effects. For example, staging may be set to not send email.\n\n- Staging may have anonymized data; the data can be fake, but it should be\n realistic. Because staging is a place to safely debug problems, you might give\n broader team access to staging data than production data. So, to protect user\n privacy, you shouldn't use actual user data in staging.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Production (prod) environments**\n\n\u003cbr /\u003e\n\nFor each application that you maintain, you need a single production\nenvironment. This is the instance with which your users interact.\n\nUnlike the other environments where you can change, delete, and/or recreate\ndata, the data in your prod environment is very important; losing or altering\nyour prod data will directly affect your users.\n\nIn the Firebase console, we recommend tagging the Firebase project associated\nwith your production environment as a\n[\"production\" environment type](/support/faq#set-environment-type). This tag\ncan help remind you and your teammates that any changes could affect your\nassociated production apps and their data.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n| **Tip** : Integrations with analytics services, including Google Analytics, often require special attention when you're setting up a new environment. You also don't want your tests from pre-production environments to impact production analytics.\n|\n| We recommend not setting up analytics for most pre-production environments,\n| unless you want to specifically test analytics integrations, like making\n| sure the right parameters are being sent to your analytics service.\n\nNext steps\n\n- Review our [general best practices](/docs/projects/dev-workflows/general-best-practices)\n for setting up Firebase projects. This guide answers questions about Firebase\n project hierarchy, how to register your app variants, and multi-tenancy.\n\n- Review the [general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\n for different environments. You want to make sure each environment and its\n data are secure.\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]
