קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בדף הזה מפורטות שיטות מומלצות כלליות וכלליות להגדרת 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
project:
צריך לוודא שכל האפליקציות שרשומות בפרויקט Firebase הן וריאציות של פלטפורמה
של אותה אפליקציה מנקודת מבט של משתמש קצה. רושמים את ה-iOS
ב-Android ובגרסאות לאינטרנט של אותו אפליקציה או משחק עם אותה Firebase
פרויקט.
אם יש לך מספר גרסאות build שיכולות להיות באותו מיקום ב-Firebase
משאבים, רושמים את הווריאנטים באותו פרויקט ב-Firebase. במידה מסוימת
לדוגמה: בלוג ואפליקציית אינטרנט באותו פרויקט, או שתי אפליקציות חינמיות
גרסאות בתשלום של אותה אפליקציה באותו פרויקט.
אם יש לכם מספר וריאנטים של גרסאות build שמבוססים על סטטוס הפרסום (ולא על פעילות או גישה משותפים של משתמשי קצה, כמו למעלה), צריך לרשום כל וריאנט בפרויקט Firebase נפרד. לדוגמה, גרסה לניפוי באגים לעומת גרסה לפריסה – צריך לרשום כל אחת מהגרסאות האלה בפרויקט Firebase משלה.
אסור להגדיר גרסאות build שמבוססות על סטטוס הגרסה עם אותם משאבים ב-Firebase
כי זה עלול לגרום לזיהום הנתונים של ניפוי הבאגים או אפילו לבטל את המוצר
.
הווריאנטים של הפלטפורמה של כל אחת מהווריאציות ה-build האלה צריכים להיות
אותו פרויקט Firebase. לדוגמה, רשמו גם את iOS וגם את Android
גרסאות build לניפוי באגים ב-"dev" לפרויקט Firebase, כי שניהם יכולים לקיים אינטראקציה עם
אותם נתונים ומשאבים שאינם של המוצר.
הימנעות מריבוי דיירים (multi-tenancy)
ריבוי דיירים עלול להוביל לבעיות חמורות שקשורות להגדרות ולפרטיות הנתונים,
כולל בעיות לא מכוונות בצבירת ניתוח נתונים, אימות משותף,
מבנים מורכבים מדי של מסדי נתונים וקשיים עם כללי אבטחה.
באופן כללי, אם קבוצת אפליקציות לא חולקת את אותם נתונים והגדרות אישיות,
מומלץ מאוד לרשום כל אפליקציה עם פרויקט Firebase שונה.
לדוגמה, אם אתם מפתחים אפליקציית תווית לבנה, כל אחד בנפרד
לאפליקציה שמסומנת בתווית צריכה להיות פרויקט Firebase משלה, ול-iOS ול-Android
גרסאות של התווית הזו צריכות להיות באותו פרויקט ב-Firebase. כל אחד
אפליקציה שתויגה באופן עצמאי לא אמורה (מטעמי פרטיות) לשתף נתונים עם
אחרים.
השלבים הבאים
כדאי לקרוא את
הנחיות אבטחה כלליות
לסביבות שונות. אתם צריכים לוודא שכל סביבה
הנתונים מאובטחים.
[null,null,["עדכון אחרון: 2025-07-25 (שעון UTC)."],[],[],null,["This 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\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\nWhere 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 **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\nAvoiding multi-tenancy **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- 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)."]]
בתרשים הזה מוצגת ההיררכיה הבסיסית של פרויקט ב-Firebase. הנה המפתח
קשרים: