Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Für Produktions-Apps benötigen Sie einen klaren Entwicklungsworkflow, insbesondere
wenn mehrere Personen an Ihrer App arbeiten. Einen Entwicklungs-Workflow
umfasst in der Regel die Einrichtung und Verwaltung
mehrerer Umgebungen.
Firebase unterstützt Entwickler-Workflows und die
einzelnen Umgebungen. Sobald Sie mit den Begriffen für
Entwickler-Workflows vertraut sind,
und Annahmen auf dieser Seite finden Sie in unserem
allgemeine Best Practices
und
allgemeine Sicherheitsrichtlinien
zum Einrichten eines Firebase-Projekts und Ihrer Apps.
Informationen zu Umgebungen
In der Softwareentwicklung bezeichnet eine Umgebung die gesamte Hardware und Software, die zum Ausführen einer Instanz einer Anwendung oder eines Anwendungssystems erforderlich ist.
Mehrere Umgebungen bieten Isolation für die Entwicklung und das Testen von Software
ohne die Nutzenden zu beeinträchtigen. Wie in der folgenden Abbildung dargestellt,
auf hoher Ebene sind entweder Vorproduktion oder Produktion.
so viele Vorproduktionsumgebungen wie nötig haben. Das Diagramm beschreibt auch gängige Praktiken und Funktionen, die mit den einzelnen Umgebungstypen verbunden sind.
Der Prozess, bei dem ein Feature oder Release durch diese Umgebungen in die Produktion verschoben wird, wird als Bereitstellungspipeline bezeichnet.
Arten von Umgebungen
Eine Umgebung besteht aus der zugrunde liegenden Infrastruktur, die Sie ausführen müssen
und unterstützen Ihre Anwendung, ihren Code und ihre Daten. Maximieren Sie die einzelnen
der folgenden Begriffe, um Beschreibungen einiger üblicher Umgebungen zu erhalten, einschließlich
zu den Datentypen, die in den einzelnen Umgebungstypen verwendet werden.
Entwicklungsumgebungen
Jeder Entwickler benötigt eine Entwicklungsumgebung – einen sicheren, abgeschotteten Ort, an dem Änderungen während der Entwicklung getestet werden können. Im Idealfall hat jeder Entwickler in Ihrem Team
in ihrer eigenen Entwicklungsumgebung. Wenn die Entwicklungsumgebung eine lokale Instanz ist,
Entwickelnde viel schneller iterieren können.
Die Daten in einer Entwicklungsumgebung sind mit Daten versehen, die im Allgemeinen der
Produktionsdaten, sollten jedoch niemals die Daten. Möglicherweise
Daten enthalten, die in der Vergangenheit Fehler verursacht haben, wie zum Beispiel sehr lange Zeichenfolgen.
Test- und QA-Umgebungen
Wenn Sie automatisierte Tests nutzen, benötigen Sie eine Umgebung, in der diese ausgeführt werden können.
und Sie müssen die Daten bei jedem Start des Tests zurücksetzen.
zu verbessern.
Wenn Sie mit QA-Entwicklern zusammenarbeiten, benötigen diese möglicherweise eine einzige Umgebung, die sie alle verwenden, oder
Zum Testen eines neuen Releasekandidaten benötigen sie möglicherweise individuelle Umgebungen.
Die Daten in Test- und QA-Umgebungen
werden mit hochwertigen Daten gespeist,
die im Allgemeinen repräsentativ sind für die Produktionsdaten, zusammen mit Daten, die
und Beispiele für Daten, die in der Vergangenheit Fehler verursacht haben.
Staging-Umgebungen
Für realistische Tests der Funktionsweise eines Release in der Produktion benötigen Sie ein Staging
Umgebung, in der die Produktionsinfrastruktur möglichst genau nachgeahmt wird. Es ist
ist es üblich, mehrere Staging-Instanzen zu haben, wenn Sie bestimmte
Integrationen isoliert.
Häufige Unterschiede zwischen Staging und Produktion:
In der Staging-Umgebung fehlen möglicherweise einige Funktionen oder Integrationen, die Nebenwirkungen verursachen könnten. So kann das Staging beispielsweise so eingestellt werden, dass keine E-Mails gesendet werden.
Für die Staging-Umgebung können anonymisierte Daten verwendet werden. Die Daten können auch gefälscht sein, sollten aber realistisch sein. Da im Staging-Bereich Probleme sicher behoben werden können, können Sie einem größeren Team Zugriff auf Staging-Daten gewähren als auf Produktionsdaten. Aus Datenschutzgründen sollten Sie daher keine tatsächlichen Nutzerdaten im Staging verwenden.
Produktionsumgebungen (prod)
Für jede Anwendung, die Sie verwalten, benötigen Sie einen einzelnen Produktions-
zu verbessern. Dies ist die Instanz, mit der Ihre Nutzer interagieren.
Im Gegensatz zu anderen Umgebungen, in denen Sie Änderungen vornehmen, löschen und/oder neu erstellen können
sind die Daten in Ihrer Produktumgebung sehr wichtig. verlieren oder verändern
dass sich Ihre Produktionsdaten direkt auf die Nutzenden auswirken.
Wir empfehlen, das zugehörige Firebase-Projekt in der Firebase-Konsole zu taggen.
mit Ihrer Produktionsumgebung als
„Produktion“ Umgebungstyp. Dieses Tag
können Sie und Ihre Teammitglieder daran erinnern, dass sich Änderungen
zugehöriger Produktions-Apps und deren Daten.
Nächste Schritte
Allgemeine Best Practices
zum Einrichten von Firebase-Projekten. In diesem Leitfaden werden Fragen zu Firebase beantwortet
Projekthierarchie, das Registrieren von Anwendungsvarianten und Mehrmandantenfähigkeit.
[null,null,["Zuletzt aktualisiert: 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)."]]
