تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تقدّم هذه الصفحة أفضل الممارسات العامة والعالية المستوى لإعداد Firebase.
المشاريع وتسجيل تطبيقاتك في مشروع حتى يتسنى لك الحصول على
سير عمل التطوير
تستخدم بيئات مميزة. بعد أن تتعرف على أفضل الممارسات في هذا المجال
يمكنك الاطّلاع على
إرشادات الأمان العامة.
فهم التسلسل الهرمي لمشروعات Firebase
يعرض هذا المخطّط البياني التسلسل الهرمي الأساسي لمشروع Firebase. إليك أهم التفاصيل
العلاقات:
يشبه مشروع Firebase حاوية جميع تطبيقاتك وأي موارد.
والخدمات المقدمة للمشروع.
يمكن أن يتضمّن مشروع Firebase تطبيقًا واحدًا أو أكثر على Firebase مسجَّلاً فيه
(على سبيل المثال، إصدارا التطبيق المخصّصَين لنظامَي التشغيل iOS وAndroid، أو إصدارَي التطبيق المجانيين
والمدفوعَين).
تشترك جميع تطبيقات Firebase المسجّلة في مشروع Firebase نفسه
الوصول إلى جميع الموارد والخدمات نفسها المتوفرة للمشروع.
وإليك بعض الأمثلة:
تشترك جميع تطبيقات Firebase المسجّلة في مشروع Firebase نفسه بالطريقة نفسها
الخلفيات، مثل Firebase Hosting وAuthentication وRealtime Database وCloud FirestoreCloud Storage، وCloud Functions.
إنّ جميع تطبيقات Firebase المسجّلة في مشروع Firebase نفسه مرتبطة
بموقع "إحصاءات Google" نفسه، حيث يكون كل تطبيق من تطبيقات 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
إصدار تصحيح الأخطاء في "dev" مشروع Firebase لأنه يمكن لكليهما التفاعل مع
نفس البيانات والموارد غير التابعة للإنتاج.
تجنُّب الإقامة المتعددة
يمكن أن يؤدي تعدّد الإيجارات إلى حدوث مشاكل خطرة في ما يتعلّق بالتهيئة وخصوصية البيانات،
بما في ذلك المشكلات غير المقصودة في تجميع التحليلات والمصادقة المشتركة
وهياكل قواعد البيانات شديدة التعقيد، والصعوبات المتعلقة بقواعد الأمان.
بوجه عام، إذا لم تشارك مجموعة من التطبيقات البيانات والتهيئات نفسها،
يجب التفكير في تسجيل كل تطبيق بمشروع مختلف على Firebase.
على سبيل المثال، إذا قمت بتطوير تطبيق تسمية أولية، فإن كل تطبيق
يجب أن يكون للتطبيق المُصنف مشروع خاص به في Firebase، وأن يعمل نظاما التشغيل iOS وAndroid
يجب أن تكون نُسخ هذا التصنيف ضمن مشروع Firebase نفسه. على كل
التطبيق الذي يحمل تصنيفًا مستقلاً (لأسباب تتعلق بالخصوصية) عدم مشاركة البيانات مع
آخرون.
الخطوات التالية
مراجعة
إرشادات الأمان العامة
للبيئات المختلفة. تريد التأكد من أن كل بيئة و
أمان البيانات.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)."]]