طرق بديلة للنشر في "استضافة التطبيقات"

في معظم الأحيان، ننصح باستخدام عمليات الطرح التلقائية أو عمليات الطرح التي يتم تفعيلها يدويًا من وحدة تحكّم "Firebase". ومع ذلك، قد يكون لديك استخدام لتدفق نشر أكثر تخصيصًا. يتضمّن App Hosting خيارات متعدّدة للنشر المخصّص.

النشر من المصدر

يتيح لك النشر من المصدر إرسال الرمز المصدر لتطبيقك وإعداداته مباشرةً إلى App Hosting بدون الحاجة إلى اتصال دائم بـ GitHub.

عند النشر من المصدر، تحمّل أداة App Hosting الرمز المصدر إلى حزمة Google Cloud Storage، وتنفّذ أمر إنشاء إطار العمل في Cloud Build، وتنشر العناصر المجمّعة في Cloud Run وCloud CDN. يتم استخدام عملية الإنشاء نفسها لعمليات النشر من المصدر المحلي وعمليات النشر من GitHub. إذا كان ملف .gitignore موجودًا في مشروعك، يتم استبعاد الملفات والمجلدات المدرَجة فيه من عملية النشر.

يمكنك النشر من مصدر محلي باستخدام واجهة سطر الأوامر في Firebase أو وحدة تحكّم Firebase.

أذونات "إدارة الهوية وإمكانية الوصول" المطلوبة وإعداد البنية الأساسية

بما أنّ كلاً من واجهة سطر الأوامر في Firebase ووحدة تحكّم Firebase يستخدمان البنية الأساسية نفسها في الخلفية لتخزين أرشيفات المصدر وإنشائها، تنطبق متطلبات إذن إدارة الهوية وإمكانية الوصول نفسها على كلتا طريقتَي النشر.

تعتمد المتطلبات الدقيقة على ما إذا كنت تنشر في موقع (منطقة) معين لأول مرة أم لا. لمزيد من المعلومات عن الأذونات، يُرجى الاطّلاع على نظرة عامة على إدارة الهوية وإمكانية الوصول في Firebase وأذونات Firebase App Hosting المحدّدة.

أذونات الإعداد الأولي (أول عملية نشر في موقع جغرافي)

عند بدء نشر المصدر المحلي في موقع المشروع لأول مرة، يجب أن توفّر "App Hosting" حزمة GCS لتخزين أرشيفاتك ومنح وكيل خدمة "App Hosting" إذن الوصول إليها. بما أنّ هذه المهام إدارية على مستوى المشروع، فهي تتطلّب أذونات مالك المشروع أو مشرف إدارة الهوية وإمكانية الوصول. لا يمكن للمستخدم الذي لديه دور "محرِّر" أو "مُشاهد" أساسي إجراء عملية الإعداد الأولية هذه وسيتم حظره.

تشمل أذونات الإعداد الأساسية ما يلي:

• تفعيل Storage API: serviceusage.services.enable
• إنشاء حزمة المصدر: storage.buckets.create وstorage.buckets.list
• ضبط وكيل الخدمة: resourcemanager.projects.setIamPolicy لمنح App Hosting إذن الوصول للقراءة (roles/storage.objectViewer) حتى يتمكّن من جلب الرمز الذي تم تحميله أثناء عمليات الإنشاء

بالنسبة إلى عملية النشر الأولية، يتم إنشاء حزمة GCS مع دورة حياة مدتها 30 يومًا، وبعد ذلك يتم حذف الحزمة. ومع ذلك، يمكنك إدارة هذا الإطار الزمني في وحدة تحكّم Cloud ضمن Cloud Storage -> حِزم البيانات -> دورة الحياة -> القواعد. يُرجى الاطّلاع على إدارة دورات حياة العناصر.

أذونات عمليات النشر اللاحقة (بعد إعداد الموقع الجغرافي)

بعد إعداد حزمة المصدر وعمليات ربط الأدوار لموقع جغرافي معيّن (إما من خلال عملية نشر أولية لواجهة سطر الأوامر أو إعداد وحدة التحكّم)، يمكن للمطوّرين أو المحرّرين أو مشرفي App Hosting العاديين نشر التحديثات. ولا تكون أذونات الإدارة على مستوى المشروع مطلوبة لعمليات النشر الروتينية.

تشمل أذونات النشر النشطة ما يلي:

• التحقّق من الحزمة: storage.buckets.list
• تحميل أرشيف المصدر: storage.objects.create
• بدء عملية الإنشاء والطرح: أذونات App Hosting العادية (apphosting.builds.create وapphosting.rollouts.create)

النشر من المصدر باستخدام واجهة سطر الأوامر (CLI) في Firebase

تتيح لك واجهة سطر الأوامر في Firebase، الإصدار 14.4.0 والإصدارات الأحدث، إرسال الرمز المصدر لتطبيقك وإعداداته مباشرةً من جهازك المحلي إلى Firebase. يُعدّ ذلك مفيدًا إذا كنت تدير عمليات نشر أخرى في Firebase (مثل قواعد الأمان أو الدوال) وتريد نشر تطبيق الويب وخدمات الخلفية معًا باستخدام أمر واحد في واجهة سطر الأوامر.

المتطلبات الأساسية

• يجب أن تكون مشاريعك ضمن خطة Blaze.
• يجب استخدام الإصدار 14.4.0 من firebase-tools أو إصدار أحدث.

خطوات النشر

1. نفِّذ الأمر firebase init apphosting في دليل مشروع على جهاز المستخدم.
2. عندما يُطلب منك ذلك، اختَر استخدام مشروع حالي واختَر مشروع Firebase المستهدف.
3. اختَر إما خلفية جديدة أو حالية للنشر فيها، حيث تعمل هذه الخطوة على إعداد عمليات نشر App Hosting للدليل المحلي وتطلب منك تفاصيل الضبط:
   • رقم تعريف الخلفية المطلوب النشر فيها
   • المنطقة التي سيتم النشر فيها، في حال إنشاء خلفية جديدة
   • المسار إلى الدليل الجذري للرمز البرمجي للتطبيق
   • بيئة تشغيل Node.js المفضّلة لديك يؤدي اختيار بيئة تشغيل ذات إصدار محدّد إلى تفعيل ميزة التحديثات التلقائية للصورة الأساسية (ABIU) لتطبيق التصحيحات البرمجية الأمنية تلقائيًا على البيئة الأساسية.
4. يحفظ App Hosting إعدادات النشر المفضّلة في firebase.json، ويُنشئ الملف في مشروع على جهاز المستخدم إذا لم يكن متوفّرًا. بعد اكتمال عملية الإعداد بنجاح، شغِّل firebase deploy لنشر الرمز المصدر.

مثال على ملف firebase.json

{
  "apphosting": [
    {
      "backendId": "my-backend",
      // rootDir specifies the directory containing the app to deploy, but the entire
      // parent directory of firebase.json will be zipped and uploaded to ensure that
      // dependencies outside of the app directory will be available at build time.
      "rootDir": "./my-app",
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log",
        "functions"
      ]
    }
  ]
}

النشر باستخدام وحدة تحكّم Firebase (تحميل ملف ZIP)

توفّر وحدة تحكّم Firebase واجهة رسومية لنشر التطبيقات من خلال تحميل أرشيف مصدر مضغوط مباشرةً. ويُعدّ هذا بديلاً عن عملية الربط بـ GitHub، في الحالات التي تفضّل فيها عدم استخدام GitHub أو تفضّل إعدادًا مختلفًا للتكامل المستمر/التسليم المستمر.

يمكن تحميل الأرشيف أثناء إنشاء الخلفية الأولية أو عند إنشاء عملية طرح يدوية على خلفية حالية، بما في ذلك الخلفيات التي تم نشرها في الأصل باستخدام واجهة سطر الأوامر في Firebase.

التنسيقات المتوافقة

تتحقّق أداة التحميل في وحدة التحكّم من صحة تنسيقَين للأرشيف المضغوط وتقبلهما:

• .zip
• .tgz

يتم عرض هذه التنسيقات بوضوح في نص وصف أداة تحميل الملفات.

خطوات النشر

الخيار (أ): أثناء عملية الإعداد الأوّلية في الخلفية

1. اختيار المصدر: في معالج إنشاء الخلفية، اختَر تحميل ملف ZIP أثناء خطوة "كيف تريد استيراد تطبيقك؟".
2. التحضير للإعداد: يؤدي النقر على "التالي" إلى بدء عملية التحضير في الخلفية، والتي تفعّل Storage API بشكل تسلسلي، وتضمن إعداد الأدوار الصحيحة، وتُنشئ الحزمة أو تعدّلها. تعرض واجهة المستخدم مؤشر تحميل مع رسائل حالة ديناميكية: "جارٍ تفعيل واجهة برمجة التطبيقات..." "جارٍ التحقّق من الأذونات..." و"جارٍ إعداد الحزمة...".
   • معالجة الأخطاء وإجراءات الحماية: في حال تعذُّر تنفيذ أي خطوة من خطوات الإعداد (مثل تلقّي مستخدم ليس مالكًا لرسالة 403 PERMISSION_DENIED بسبب عدم كفاية أذونات "إدارة الهوية وإمكانية الوصول")، تعرض واجهة المستخدم تحذيرًا مخصّصًا يطلب منك التواصل مع مالك المشروع. يتم قفل التنقّل في الخطوات بشكل صارم، ويظل زر "التالي" والزر النهائي "إنهاء ونشر" غير مفعَّلين إلى أن يتم حل المشكلة.
3. تحميل الملفات: بعد اكتمال عملية التحضير بنجاح، اختَر ملف الأرشيف أو اسحبه إلى أداة تحميل الملفات.

4. ضبط الإعدادات: حدِّد دليل جذر التطبيق (الإعداد التلقائي هو /).

5. انقر على إنهاء ونشر: يتم إيقاف زر "إنهاء" المستقل لعمليات تحميل ملفات ZIP لأنّ تحميل الأرشيف هو إجراء يتم لمرة واحدة ويجب أن يتبعه على الفور عملية نشر لضمان عمل الخلفية بشكل صحيح.

الخيار (ب): إنشاء عملية طرح يدوي

1. فتح مربّع الحوار: في لوحة بيانات App Hosting، انقر على إنشاء عملية طرح.
2. اختيار المصدر: انقر على تحميل ملف ZIP في مربّع الحوار. إذا لم يكن لدى الخلفية اتصال حالي بـ GitHub، يتم إيقاف خيار "GitHub".
3. التحضير والتحميل: يؤدي الاختيار إلى بدء عملية التحضير نفسها في الخلفية ("تفعيل واجهة برمجة التطبيقات..."، "جارٍ التحقّق من الأذونات..." و"جارٍ إعداد الحزمة..."). بعد نجاح العملية، اسحب ملف الأرشيف أو اختَره باستخدام أداة التحميل، وحدِّد دليل جذر التطبيق، ثم انقر على نشر لبدء عملية الإنشاء والطرح.

النشر باستخدام Terraform

إذا كنت بحاجة إلى مزيد من التحكّم في عملية الإنشاء والبيئة المنشورة، يمكنك النشر باستخدام Terraform. تتيح لك أداة Terraform تحديد موارد App Hosting وإدارتها باستخدام ملفات الإعداد التعريفية، كما تتيح لك نشر صورة الحاوية المُنشأة مسبقًا مباشرةً في App Hosting بدلاً من الاعتماد على App Hosting لإنشاء الصورة من الرمز المصدر.

إذا كنت مستخدمًا جديدًا لـ Terraform، يمكنك الاطّلاع على بدء استخدام Terraform وFirebase. إذا كنت على دراية بـ Terraform، يمكنك البدء باستخدام نماذج ملفات الإعداد وموارد App Hosting الأخرى.

إعداد عملية ربط GitHub لضمان التكامل المستمر/التسليم المستمر (CI/CD)

يمكنك ربط مستودع GitHub في أي وقت من خلال علامة التبويب النشر في إعدادات الخلفية في وحدة تحكّم "Firebase". يتيح لك ذلك نشر نموذج أوّلي للتطبيق من بيئة محلية، ثم الانتقال إلى مسارَي التعلّم "الدمج المستمر" (CI) أو "النشر المستمر" (CD) الآليَّين عندما تكون مستعدًا.

النشر باستخدام أدوات الذكاء الاصطناعي

سنوقف خدمة "Firebase Studio" نهائيًا في 22 مارس 2027. مع أنّ الخلفيات في App Hosting لن تتأثر، سيتم إيقاف الزر نشر في Firebase Studio. لمواصلة نشر التحديثات بدون تغيير عنوان URL، عليك نقل مشروعك. كيفية نقل البيانات