إذا كانت عمليات الطرح التلقائية مفعّلة، في كل مرة تنقل فيها التزامًا جديدًا إلى الفرع المباشر في مستودع GitHub، يطرح App Hosting تلقائيًا إصدارًا جديدًا من تطبيقك. ويمكنك الاطّلاع على حالة الطرح في Firebase console أو في App Hosting GitHub check.
بالإضافة إلى ذلك، تتيح App Hosting عمليات الطرح التي يتم تفعيلها يدويًا من أجل دمج التكامل المستمر/النشر المستمر (CI/CD) أو أي حالة أخرى تريد فيها فرض عملية طرح.
عرض عمليات الطرح
يتيح لك Firebase console الوصول إلى معلومات مفصّلة عن جميع عمليات طرح تطبيقك.
انتقِل إلى الاستضافة والخدمات بلا خادم> استضافة التطبيقات، ثم انقر على عرض للواجهة الخلفية التي تريد الاطّلاع على عمليات طرحها. تعرِض علامة التبويب عمليات الطرح للواجهة الخلفية جدولاً يتضمّن سجلّاً بجميع عمليات طرح هذه الواجهة الخلفية.
يحتوي كل إدخال لعملية طرح على روابط تؤدي إلى مهمة Cloud Build و التغيير أو الالتزام الذي أدّى إلى تفعيل عملية الطرح، بالإضافة إلى معلومات أساسية عن المؤلّف وتاريخ الإنشاء وحالة عملية الطرح.
- مهمة Cloud Build هي بيئة الإنشاء التي تنفّذ فيها App Hosting أمر إنشاء تطبيقك. يمكنك الوصول إلى سجلّات Cloud Build من خلال النقر على رقم تعريف الإنشاء.
- التغيير هو التزام GitHub أو أي إجراء آخر أدّى إلى تفعيل عملية الطرح.
تفعيل عملية طرح يدويًا
إذا أردت تفعيل عملية طرح يدويًا من مصدر GitHub بدون نقل التزام جديد، يمكنك إنشاء عملية طرح من Firebase console أو the Firebase CLI. ويكون ذلك مفيدًا في حالات مثل:
- فرض إعادة إنشاء المحتوى الثابت
- السماح لنظام التكامل المستمر/النشر المستمر (CI/CD) بتفعيل عمليات الطرح
- حصر عمليات طرح الإنتاج في تواريخ أو أوقات معيّنة
لتفعيل عملية طرح في Firebase console:
- في Firebase console، انتقِل إلى الاستضافة والخدمات بلا خادم > استضافة التطبيقات.
- انقر على عرض للواجهة الخلفية التي تريد إنشاء عملية طرح لها.
- في لوحة بيانات الواجهة الخلفية، انقر على إنشاء عملية طرح.
- اختَر الفرع الذي تريد نشره.
- اختَر الالتزام الذي تريد نشره، سواء كان أحدث التزام أو التزامًا سابقًا محدّدًا برقم تعريف الالتزام.
- انقر على إنشاء. تظهر الحالة ورقم الإنشاء لعملية الطرح في جدول سجلّ عمليات الطرح. عند اكتمال عملية الطرح، تظهر هذه العملية كعملية الطرح الحالية.
لتفعيل عملية طرح في Firebase CLI، نفِّذ الأمر التالي و اختر الفرع لعملية الطرح عند المطالبة بذلك:
firebase apphosting:rollouts:create BACKEND_ID
بدلاً من ذلك، يمكنك بدء عملية طرح لأحدث التزام لفرع معيّن باستخدام الخيار --git-branch:
firebase apphosting:rollouts:create BACKEND_ID
--git_branch BRANCH_NAME
يمكنك أيضًا إنشاء عملية طرح باستخدام التزام معيّن باستخدام الخيار --git-commit:
firebase apphosting:rollouts:create BACKEND_ID
--git_commit COMMIT_ID
استعادة عملية طرح سابقة
App Hosting تمنحك خيارَين لاستعادة عملية طرح سابقة:
- التراجع فورًا بدون إعادة الإنشاء
- إعادة الإنشاء والتراجع إلى إصدار سابق
إنشاء عملية تراجع فورية
في بعض الأحيان، قد تحتاج إلى الرجوع سريعًا إلى إصدار أقدم من تطبيقك، مثلاً إذا اكتشفت خطأً فادحًا في عملية طرح تم نشرها حديثًا أو إذا كنت تواجه عملية إنشاء غير مستقرة تمنع عمليات الطرح الجديدة. في هذه الحالات، يمكنك استعادة صورة حاوية حالية من اختيارك من عملية طرح سابقة. لا تتم إعادة إنشاء هذه الصورة، ولكن يتم استخدام رمز وبيئة الإعدادات من وقت إنشائها لأول مرة.
لإنشاء عملية تراجع فورية:
- في Firebase console، انتقِل إلى الاستضافة والخدمات بلا خادم > استضافة التطبيقات.
- انقر على عرض للواجهة الخلفية التي تريد إنشاء عملية تراجع لها.
- انقر على علامة التبويب عمليات الطرح.
- في جدول السجلّ للواجهة الخلفية، انقر على قائمة النقاط الثلاث لإنشاء سابق.
- انقر على التراجع إلى هذا الإنشاء وأكِّد ذلك.
إعادة الإنشاء والتراجع
إذا أردت العودة إلى إصدار أقدم من تطبيقك مع الاحتفاظ بالإعدادات الحالية، يمكنك إعادة إنشاء التطبيق كجزء من عملية العودة إلى الحالة السابقة. على سبيل المثال، إذا عدّل أحدث إصدار قيمة مفتاح واجهة برمجة التطبيقات في Secret Manager، يمكن أن تضمن عملية إعادة الإنشاء استخدام المفتاح الجديد في تطبيقك بعد التراجع.
لإعادة الإنشاء والتراجع:
- في Firebase console، انتقِل إلى الاستضافة والخدمات بلا خادم > استضافة التطبيقات.
- انقر على عرض لوحة البيانات للواجهة الخلفية التي تريد إنشاء عملية تراجع لها.
- انقر على علامة التبويب عمليات الطرح.
- انقر على إنشاء عملية طرح.
- في مربّع الحوار إنشاء عملية طرح ، انقر على التزام سابق ، ثم أدخِل رقم تعريف الالتزام للإصدار الذي تريد إعادة إنشائه والتراجع إليه. إنّ رقم تعريف الالتزام هو جزء من "تفاصيل التغيير" لكل عملية طرح مدرَجة في سجلّ عمليات الطرح ، وهو مضمّن بين أقواس في التصنيف.
- انقر على إنشاء لبدء عملية العودة إلى الحالة السابقة.
تغيير إعدادات عمليات الطرح
يمكنك تغيير الفرع المباشر لعمليات الطرح وإيقاف عمليات الطرح التلقائية أو تفعيلها باستخدام عناصر التحكّم في طريقة العرض الإعدادات > النشر في لوحة بيانات الواجهة الخلفية.
- في Firebase console، انتقِل إلى الاستضافة والخدمات بلا خادم > استضافة التطبيقات.
- انقر على عرض للواجهة الخلفية التي تريد تعديل إعدادات عمليات الطرح فيها.
- في لوحة بيانات الواجهة الخلفية، انقر على الإعدادات. تعرِض طريقة العرض التلقائية معلومات عن النطاقات والنطاقات المخصّصة.
- انقر على طريقة العرض النشر. في طريقة العرض هذه، يمكنك تغيير الفرع المباشر لعمليات الطرح وإيقاف عمليات الطرح التلقائية أو تفعيلها. بالإضافة إلى ذلك، هناك خيارات لضبط دليل جذر التطبيق والبيئة للواجهة الخلفية (راجِع النشر في بيئات متعددة).
إدارة عمليات الطرح التلقائية
تفترض App Hosting تلقائيًا قائمة "مطلوبة" بـ جميع الملفات، ما يعني أنّ كل التزام جديد في مستودعك يؤدي إلى تفعيل عملية إنشاء وطرح جديدة. ومع ذلك، لتوفير الوقت ومنع عمليات النشر غير الضرورية، يمكنك ضبط App Hosting لتخطّي عمليات الإنشاء استنادًا إلى مسارات الملفات المحدّدة التي تم تعديلها في التزام.
يمكنك ضبط ذلك ضِمن الإعدادات > عمليات الطرح > مشغّلات عمليات الطرح. هنا، يمكنك ترك حقل المسارات المطلوبة فارغًا إذا أردت أن يؤدي كل التزام جديد في مستودعك إلى تفعيل عملية إنشاء وطرح جديدة، أو يمكنك تحديد الأدلة أو الملفات التي يجب أن تؤدي دائمًا إلى تفعيل عملية طرح. إذا حدّدت الأدلة، احرص على إضافة جميع المسارات التي يجب أن تؤدي التغييرات فيها إلى تفعيل عملية طرح.
لن تؤدي الأدلة أو الملفات التي تضيفها إلى المسارات التي تم تجاهلها إلى تفعيل عملية طرح تلقائية مطلقًا. في الحالات التي يندرج فيها دليل فرعي ضمن كل من القائمتَين المطلوبة والمتجاهَلة، لن يتم تفعيل عملية طرح تلقائية. إذا ملأت قائمة المسارات التي تم تجاهلها فقط، سيملأ App Hosting تلقائيًا الحقل "*" للمسارات المطلوبة.
إذا نقلت التزامًا لا يتطابق فيه أي من الملفات التي تم تغييرها مع مساراتك المطلوبة
(أو إذا تم استبعاد جميع التغييرات بشكلٍ صريح من خلال مساراتك التي تم تجاهلها)،
App Hosting ستظل تقرّ باستلام حدث GitHub، ولكنها ستضع
علامة على حالتَي الإنشاء والطرح على أنهما SKIPPED، ولن يتم تفعيل أي عملية طرح تلقائية.