بهترین روش های عمومی برای راه اندازی پروژه های Firebase
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
این صفحه بهترین روشهای عمومی و سطح بالا را برای راهاندازی پروژههای Firebase و ثبت برنامههایتان در یک پروژه ارائه میکند تا گردش کار توسعه واضحی داشته باشید که از محیطهای مجزا استفاده میکند. هنگامی که با بهترین شیوه های این صفحه آشنا شدید، دستورالعمل های امنیتی عمومی ما را بررسی کنید.
آشنایی با سلسله مراتب پروژه های Firebase
این نمودار سلسله مراتب اساسی یک پروژه Firebase را نشان می دهد. در اینجا روابط کلیدی وجود دارد:
پروژه Firebase مانند محفظه ای برای همه برنامه های شما و هر منبع و سرویسی است که برای پروژه ارائه شده است.
یک پروژه Firebase میتواند یک یا چند برنامه Firebase را در آن ثبت کرده باشد (برای مثال، هر دو نسخه iOS و Android یک برنامه، یا هر دو نسخه رایگان و پولی یک برنامه).
همه برنامههای Firebase در یک اشتراک پروژه Firebase ثبت شدهاند و به همه منابع و سرویسهای ارائهشده برای پروژه دسترسی دارند . در اینجا چند نمونه آورده شده است:
همه برنامههای Firebase که در پروژه Firebase یکسانی ثبت شدهاند، پشتیبانهای یکسانی دارند، مانند Firebase Hosting ، Authentication ، Realtime Database ، Cloud Firestore ، Cloud Storage و Cloud Functions .
همه برنامههای Firebase ثبتشده در یک پروژه Firebase با همان ویژگی Google Analytics مرتبط هستند، جایی که هر برنامه Firebase یک جریان داده جداگانه در آن ویژگی است.
یک پروژه Google Cloud در کجای این سلسله مراتب قرار می گیرد؟
یکی از جنبه های سلسله مراتب پروژه Firebase که در نمودار بالا نشان داده نشده است، ارتباط با پروژه Google Cloud است. پروژه Firebase در واقع فقط یک پروژه Google Cloud است که تنظیمات و سرویسهای اضافی مخصوص Firebase را برای آن فعال کرده است. توجه داشته باشید که همه برنامههای ثبتشده در یک پروژه Firebase نیز به منابع و سرویسهای Google Cloud یکسان اشتراکگذاری میکنند و به آنها دسترسی دارند.
در اینجا چند نکته مهم برای ثبت انواع برنامه های خود در پروژه Firebase آورده شده است:
اطمینان حاصل کنید که همه برنامههای ثبتشده در پروژه Firebase از دیدگاه کاربر نهایی ، انواع پلتفرم یک برنامه مشابه هستند. نسخه iOS، Android، و نسخه وب یک برنامه یا بازی را با همان پروژه Firebase ثبت کنید.
اگر چندین نسخه ساخت دارید که می توانند منابع Firebase یکسان را به اشتراک بگذارند ، انواع را با پروژه Firebase یکسان ثبت کنید. برخی از نمونه ها یک وبلاگ و یک برنامه وب در یک پروژه یا هر دو نسخه رایگان و پولی یک برنامه در یک پروژه هستند.
اگر چندین نسخه ساخت دارید که بر اساس وضعیت انتشار هستند (به جای فعالیت یا دسترسی مشترک کاربر نهایی، مانند بالا)، هر گونه را با یک پروژه Firebase جداگانه ثبت کنید. یک مثال اشکال زدایی در مقابل نسخه انتشار است - هر یک از این ساخت ها را در پروژه Firebase خود ثبت کنید.
ساختهای مبتنی بر وضعیت انتشار نباید منابع Firebase یکسان را به اشتراک بگذارند زیرا این خطر باعث آلودگی دادههای اشکالزدایی شما یا حتی نادیده گرفتن دادههای تولیدی شما میشود.
انواع پلتفرم هر یک از این انواع ساخت باید در همان پروژه Firebase باشد. به عنوان مثال، هر دو بیلد اشکالزدایی iOS و Android را در پروژه Firebase "dev" ثبت کنید زیرا هر دو میتوانند با دادهها و منابع غیر تولیدکننده یکسان تعامل داشته باشند.
اجتناب از چند اجاره ای
چند اجاره ای می تواند به نگرانی های جدی در مورد پیکربندی و حفظ حریم خصوصی داده ها منجر شود، از جمله مشکلات ناخواسته با انباشت تجزیه و تحلیل، احراز هویت مشترک، ساختارهای پایگاه داده بیش از حد پیچیده، و مشکلات در قوانین امنیتی.
به طور کلی، اگر مجموعهای از برنامهها دادهها و پیکربندیهای یکسانی را به اشتراک نمیگذارند، قویاً ثبت هر برنامه را با یک پروژه Firebase متفاوت در نظر بگیرید.
به عنوان مثال، اگر یک برنامه با برچسب سفید ایجاد می کنید، هر برنامه دارای برچسب مستقل باید پروژه Firebase خود را داشته باشد و نسخه های iOS و Android آن برچسب باید در همان پروژه Firebase باشند. هر برنامه دارای برچسب مستقل (به دلایل حفظ حریم خصوصی) نباید داده ها را با دیگران به اشتراک بگذارد.
مراحل بعدی
دستورالعمل های امنیتی کلی برای محیط های مختلف را مرور کنید. شما می خواهید مطمئن شوید که هر محیط و داده های آن ایمن هستند.
تاریخ آخرین بهروزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# General best practices for setting up Firebase projects\n\nThis page provides general, high-level best practices for setting up Firebase\nprojects and registering your apps with a project so that you have a clear\n[development workflow](/docs/projects/dev-workflows/overview-environments) that\nuse distinct environments. Once you're familiar with the best practices on this\npage, check out our\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines).\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\nUnderstanding the hierarchy of Firebase projects\n------------------------------------------------\n\n\nThis diagram shows the basic hierarchy of a Firebase project. Here are the key\nrelationships:\n\n- A **Firebase project** is like a container for all your apps and any resources\n and services provisioned for the project.\n\n- A Firebase project can have one or more **Firebase Apps** registered to it\n (for example, both the iOS and Android versions of an app, or both the free\n and paid versions of an app).\n\n- All Firebase Apps registered to the same Firebase project **share and have\n access to all the same resources and services provisioned for the project**.\n Here are some examples:\n\n - All the Firebase Apps registered to the same Firebase project share the same\n backends, like Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,\n Cloud Storage, and Cloud Functions.\n\n - All Firebase Apps registered to the same Firebase project are associated\n with the same Google Analytics property, where each Firebase App is a\n separate data stream in that property.\n\n### Where does a Google Cloud project fit into this hierarchy?\n\nOne aspect of the Firebase project hierarchy that's not shown in the diagram\nabove is the relationship with a Google Cloud project. **A Firebase project is\nactually just a Google Cloud project that has additional *Firebase-specific*\nconfigurations and services enabled for it.**\nNote that all the apps registered to the same Firebase project also share and\nhave access to all the same Google Cloud resources and services, too.\n\nLearn more about the Firebase and Google Cloud relationship in\n[Understand Firebase projects](/docs/projects/learn-more#firebase-cloud-relationship)\n\nRegistering app variants with Firebase projects\n-----------------------------------------------\n\n| **Key Point:** All the apps registered to a Firebase project share and can access the same data as well as the resources and services provisioned for the project, which includes database instances, storage buckets, functions, etc.\n\nHere are some important tips for registering your app variants with a Firebase\nproject:\n\n- Ensure that all apps registered to a Firebase project are **platform variants\n of the same application** from an end-user perspective. Register the iOS,\n Android, and web versions of the same app or game with the *same* Firebase\n project.\n\n- If you have **multiple build variants that could *share the same Firebase\n resources*** , register the variants with the *same* Firebase project. Some\n examples are a blog and a web app in the same project, or both the free and\n paid versions of the same app in the same project.\n\n- If you have **multiple build variants that are *based on release status***\n (rather than on common end-user activity or access, like above), register each\n variant with a *separate* Firebase project. An example is your debug vs\n release build -- register each of these builds in its own Firebase project.\n\n - Builds based on release status should not share the same Firebase resources\n because that risks your debug data polluting or even overriding your prod\n data.\n\n - The *platform* -variants of each of these build variants should be in the\n *same* Firebase project. For example, register both the iOS and the Android\n debug builds in a \"dev\" Firebase project because they can both interact with\n the same non-prod data and resources.\n\n| **Note:** For each Android app, if you provide a SHA-1 key for the app, you need to provide a package name and SHA-1 key combination that is globally unique across all of Google Cloud.\n\n### Avoiding multi-tenancy\n\n| **Key Point:** Connecting several different logically independent apps and/or web sites to a single Firebase project (often called \"multi-tenancy\") is not recommended.\n\nMulti-tenancy can lead to serious configuration and data privacy concerns,\nincluding unintended issues with analytics aggregation, shared authentication,\noverly-complex database structures, and difficulties with security rules.\n\nGenerally, **if a set of apps don't share the same data and configurations,\nstrongly consider registering each app with a different Firebase project.**\n\nFor example, if you develop a white-label application, each independently\nlabeled app should have its own Firebase project, and the iOS and Android\nversions of that label should be in the same Firebase project. Each\nindependently labeled app shouldn't (for privacy reasons) share data with the\nothers.\n\nNext steps\n----------\n\n- Review the\n [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)."]]