تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
بالنسبة إلى تطبيقات الإنتاج، يجب وضع سير عمل واضح للتطوير، خاصةً
إذا كان هناك أكثر من مستخدم واحد يعمل على تطبيقك سير عمل التطوير
إعداد بيئات متعددة وإدارتها.
توفّر Firebase مستويات مختلفة من الدعم لسير عمل المطوّرين والاطّلاع على
البيئات المكوّنة. بعد التعرّف على بنود سير عمل المطوِّر
والافتراضات الواردة في هذه الصفحة، اطلع على
أفضل الممارسات العامة
أو
إرشادات الأمان العامة
لإعداد مشروع Firebase وتطبيقاتك.
لمحة عن البيئات
في مجال تطوير البرمجيات، تشير البيئة إلى جميع الأجهزة والبرامج
المطلوبة لتشغيل مثيل تطبيق أو نظام
التطبيقات.
توفر سلسلة من البيئات عزلة لتطوير البرامج واختبارها
بدون التأثير على المستخدمين. كما هو موضح في الرسم التخطيطي أدناه، إن البيئات في
عالية المستوى تكون إما مرحلة ما قبل الإنتاج أو الإنتاج، ويمكنك
لديها العديد من بيئات ما قبل الإنتاج حسب الحاجة. يصف الرسم التخطيطي أيضًا
الممارسات والميزات الشائعة المرتبطة بكل
لنوع البيئة.
يشير هذا المصطلح إلى عملية تطوير ميزة أو إصدار خلال هذه البيئات
مسار النشر.
أنواع البيئات
تتكون البيئة من البنية الأساسية الأساسية التي تحتاج إلى تشغيلها
ودعم تطبيقك ورموزه وبياناته. قم بتوسيع كل من
الشروط التالية لمراجعة أوصاف بعض البيئات المشتركة، بما في ذلك
ونصائح حول أنواع البيانات المستخدمة في كل نوع من أنواع البيئات.
بيئات التطوير
يحتاج كل مطوّر إلى بيئة تطوير، وهي مكان آمن ومعزول للاختبار
التغييرات أثناء إنشائها. من الناحية المثالية، يمكن لكل مطوّر في فريقك الوصول إلى
مع بيئة التطوير الخاصة بهم. وكذلك، إذا كانت بيئة dev مثيلاً محليًا،
يمكن للمطور التكرار بشكل أسرع بكثير.
يتم تأسيس البيانات الموجودة في بيئة التطوير باستخدام بيانات تشبه بشكل عام
بيانات الإنتاج، ولكن ينبغي ألا تحتوي أبدًا على أي بيانات البيانات. وقد يحتوي أيضًا
على بيانات سبّبت أخطاء في السابق، مثل سلاسل طويلة جدًا.
بيئات الاختبار وتأكيد الجودة
إذا كنت تخضع لاختبارات تلقائية، فأنت بحاجة إلى بيئة يتم فيها تشغيل هذه الاختبارات
وتحتاج إلى إعادة تعيين البيانات في كل مرة تقوم فيها بتدوير الاختبار
محددة.
إذا كان لديك مهندسون لضمان الجودة، فقد يحتاجون إلى بيئة واحدة يستخدمها جميعًا، أو
فقد تحتاج إلى بيئات فردية لاختبار مرشح جديد للإصدار.
تعتمد البيانات في بيئات الاختبار وتأكيد الجودة على بيانات عالية الجودة
ممثلة بشكل عام لبيانات الإنتاج، إلى جانب البيانات التي تمثل
حالات الزاوية وأمثلة على البيانات التي تسببت في حدوث أخطاء في الماضي.
البيئات المرحلية
لإجراء اختبارات واقعية حول آلية عمل الإصدار في مرحلة الإنتاج، يجب إجراء مرحلة
بيئة تحاكي البنية التحتية للإنتاج بأكبر قدر ممكن. من المهم
أن يكون لديك مثيلات مرحلية متعددة إذا كنت بحاجة إلى اختبار
عمليات الدمج بمعزل عن بعضها.
في ما يلي الاختلافات الشائعة بين الإنتاج المرحلي والإنتاج:
قد يفتقد التقسيم المرحلي بعض الميزات أو عمليات الدمج التي قد تتسبب في حدوث جانب
التأثيرات. على سبيل المثال، يمكن ضبط التقسيم المرحلي بحيث لا يتم إرسال الرسائل الإلكترونية.
قد يكون للتقسيم المرحلي بيانات مخفية الهوية. فقد تكون البيانات مزيفة، ولكن ينبغي
واقعي. نظرًا لأن التقسيم هو مكان لتصحيح الأخطاء بأمان، يمكنك أن تعطي
وصول فريق أوسع إلى البيانات المرحلية من بيانات الإنتاج. لذلك، لحماية المستخدم
وخصوصيتهم، يجب ألا تستخدم بيانات المستخدم الفعلية في التقسيم المرحلي.
بيئات الإنتاج (prod)
تحتاج إلى إنتاج واحد لكل تطبيق تحتفظ به.
محددة. هذا هو المثيل الذي يتفاعل معه المستخدمون.
على عكس البيئات الأخرى التي يمكنك فيها تغيير و/أو حذف و/أو إعادة إنشاء
البيانات، فإن البيانات الموجودة في بيئة الإنتاج مهمة للغاية؛ الخسارة أو التغيير
تؤثر بيانات المنتج مباشرةً في المستخدمين
في وحدة تحكّم Firebase، ننصحك بوضع علامة على مشروع Firebase المرتبط
ببيئة الإنتاج على أنّه
نوع بيئة "الإنتاج". يمكن أن تساعدك هذه العلامة
في تذكيرك أنت وزملائك بأنّ أي تغييرات قد تؤثر في
تطبيقاتك العلنية المرتبطة وبياناتها.
الخطوات التالية
مراجعة أفضل الممارسات العامة
لإعداد مشاريع Firebase. يجيب هذا الدليل عن أسئلة حول Firebase.
وتسلسل هرمي للمشروع، وكيفية تسجيل الأنواع المختلفة لتطبيقك، واشتراكات متعددة العملاء.
راجِع إرشادات الأمان العامة.
للبيئات المختلفة. تريد التأكد من أن كل بيئة و
أمان البيانات.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)."]]
