Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
W przypadku aplikacji w wersji produkcyjnej musisz zaplanować jasny proces programowania, zwłaszcza
jeśli nad aplikacją pracuje więcej niż 1 osoba. Proces programowania
zwykle wymaga skonfigurowania wielu środowisk i zarządzania nimi.
Firebase oferuje różne poziomy obsługi przepływów pracy programisty oraz
tych środowisk. Gdy już zapoznasz się z terminami w przepływie pracy programisty
i założeniami na tej stronie, zapoznaj się z
ogólne sprawdzone metody
oraz
ogólne wytyczne dotyczące bezpieczeństwa
, aby skonfigurować projekt Firebase i aplikacje.
Informacje o środowiskach
W rozwoju oprogramowania środowiskiem jest sprzęt i oprogramowanie,
które są wymagane do uruchomienia instancji aplikacji lub systemu
aplikacji.
Seria środowisk zapewnia odizolowanie od środowiska tworzenia i testowania oprogramowania
bez wpływu na użytkowników. Jak widać na schemacie poniżej, środowiska na poziomie
zasadniczo są uznawane za przedprodukcyjne lub produkcyjne.
mają tyle środowisk przedprodukcyjnych, ile jest potrzebnych. Diagram przedstawia też typowe metody i funkcje związane z poszczególnymi typami środowisk.
Proces przenoszenia funkcji lub publikowania w tych środowiskach do
w środowisku produkcyjnym jest nazywany potokiem wdrożenia.
Typy środowisk
Środowisko składa się z bazowej infrastruktury, którą musisz uruchomić
aby zapewnić obsługę aplikacji, jej kodu i danych. Rozwiń każdy
poniższych terminów, aby zapoznać się z opisami typowych środowisk, w tym
wskazówek na temat typów danych wykorzystywanych w poszczególnych typach środowisk.
Środowiska programistyczne
Każdy deweloper potrzebuje środowiska programistycznego – bezpiecznego, odizolowanego miejsca do testowania wprowadzanych zmian. W idealnej sytuacji każdy programista z Twojego zespołu ma dostęp do tych danych,
do własnego środowiska programistycznego. Poza tym, jeśli środowisko programistyczne jest instancją lokalną,
dzięki czemu programista może
szybciej tworzyć nowe wersje.
Dane w środowisku programistycznym są zapoczątkowane danymi, które zasadniczo przypominają
danych produkcyjnych, ale nie powinien zawierać żadnych i skalowalnych danych. Może też
zawierają dane, które w przeszłości spowodowały błędy, np. bardzo długie ciągi znaków.
Środowiska testowania i kontroli jakości
Jeśli używasz testów automatycznych, potrzebujesz środowiska, w którym je przeprowadzasz.
i trzeba je zresetować po każdym uruchomieniu testu.
dla środowiska.
Jeśli zatrudniasz inżynierów ds. kontroli jakości, być może będą oni potrzebować jednego środowiska, z którego korzystają wszyscy.
mogą potrzebować indywidualnych środowisk do przetestowania nowej wersji kandydującej.
Dane w środowiskach testowych i kontroli jakości zawierają dane wysokiej jakości,
zasadniczo reprezentatywnych dla danych produkcyjnych, wraz z danymi reprezentującymi
przypadków wystąpienia błędów i przykładów danych, które w przeszłości spowodowały błędy.
Środowiska testowania
Aby w realistyczny sposób sprawdzić, jak dana wersja będzie działać w środowisku produkcyjnym, potrzebujesz środowiska testowego
które maksymalnie naśladuje infrastrukturę produkcyjną. Jest
często ma wiele instancji przejściowych, jeśli trzeba przetestować określone
z integracją w oddzielnym miejscu.
Oto typowe różnice między wersją testową a produkcyjną:
W wersji testowej może brakować niektórych funkcji lub integracji, które mogą powodować działania niepożądane. Możesz na przykład ustawić konfigurację tak, aby nie wysyłać e-maili.
Testy mogą mieć zanonimizowane dane; dane mogą być fałszywe, ale powinny być
realistyczne. Ze względu na to, że testowanie jest miejscem do bezpiecznego
debugowania problemów,
szerszy dostęp zespołu do danych testowych niż do danych produkcyjnych. Aby chronić użytkowników
prywatności, podczas testowania nie używaj
rzeczywistych danych użytkownika.
Środowiska produkcyjne (prod)
Dla każdej aplikacji, którą zarządzasz, potrzebujesz jednej wersji produkcyjnej
dla środowiska. Jest to instancja, z którą użytkownicy się stykają.
W odróżnieniu od innych środowisk, w których możesz zmieniać, usuwać lub tworzyć ponownie
dane w środowisku produkcyjnym są bardzo ważne, utraty lub zmiany
Twoje dane produkcyjne będą
bezpośrednio wpływać na Twoich użytkowników.
W konsoli Firebase zalecamy otagowanie powiązanego projektu Firebase
w środowisku produkcyjnym
„produkcja” (typ środowiska). Ten tag
może przypomnieć Tobie i współpracownikom, że jakiekolwiek zmiany mogą
powiązane aplikacje produkcyjne i ich dane.
Dalsze kroki
Zapoznaj się z ogólnymi sprawdzonymi metodami.
, aby skonfigurować projekty Firebase. Ten przewodnik zawiera odpowiedzi na pytania dotyczące Firebase
hierarchii projektów, sposobu rejestrowania wariantów aplikacji oraz środowiska wielu najemców.
[null,null,["Ostatnia aktualizacja: 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)."]]
