اگر انتشار خودکار را فعال کرده باشید، هر بار که یک کامیت جدید را به شاخهی زنده در مخزن گیتهاب خود ارسال میکنید App Hosting به طور خودکار نسخه جدیدی از برنامهی شما را منتشر میکند. میتوانید وضعیت انتشار را در کنسول Firebase یا در App Hosting GitHub check بررسی کنید.
علاوه بر این، App Hosting از راهاندازیهای دستی برای ادغام CI/CD یا هر مورد دیگری که میخواهید راهاندازی را اجباری کنید، پشتیبانی میکند.
مشاهدهی فهرستها
کنسول Firebase دسترسی به اطلاعات دقیق در مورد تمام انتشارهای برنامه شما را فراهم میکند.
به Hosting & Serverless > App Hosting بروید، سپس View را برای backend ای که میخواهید rollout های آن را ببینید انتخاب کنید. تب Rollout ها برای backend جدولی را نمایش میدهد که تاریخچه تمام rollout های این backend را فهرست میکند.
هر ورودیِ انتشار شامل پیوندهایی به کار Cloud Build و تغییر یا کامیتی است که باعث انتشار شده است، به همراه اطلاعات اولیه در مورد نویسنده، تاریخ ایجاد و وضعیت انتشار.
- کار Cloud Build محیط ساختی است که App Hosting دستور ساخت برنامه شما را در آن اجرا میکند. میتوانید با کلیک روی شناسه ساخت، به گزارشهای Cloud Build دسترسی پیدا کنید.
- تغییر، کامیت گیتهاب یا اقدام دیگری است که باعث انتشار عمومی شده است.
فعال کردن دستی یک انتشار
اگر میخواهید بدون ارسال کامیت جدید، به صورت دستی یک rollout را از منبع گیتهاب خود فعال کنید، میتوانید از کنسول Firebase یا رابط خط فرمان Firebase یک rollout ایجاد کنید. این روش برای مواردی مانند موارد زیر مفید است:
- اجبار به بازسازی محتوای استاتیک.
- اجازه دادن به یک سیستم CI/CD برای راهاندازی بهروزرسانیها.
- محدود کردن عرضههای محصول به تاریخها یا زمانهای خاص.
برای فعال کردن یک rollout در کنسول Firebase :
- در کنسول Firebase ، به Hosting & Serverless > App Hosting بروید.
- برای بکاندی که میخواهید برایش یک rollout ایجاد کنید، روی View کلیک کنید.
- در خلاصه داشبورد backend، گزینه Create rollout را انتخاب کنید.
- شاخهای را برای استقرار انتخاب کنید.
- کامیت مورد نظر برای استقرار را انتخاب کنید، چه آخرین کامیت باشد و چه کامیت قبلی که با شناسه کامیت آن مشخص شده باشد.
- گزینه «ایجاد» را انتخاب کنید. وضعیت و شماره ساخت برای انتشار در جدول تاریخچه انتشار نمایش داده میشود. پس از اتمام فرآیند انتشار، این انتشار به عنوان انتشار فعلی نمایش داده میشود.
برای فعال کردن یک rollout در Firebase CLI، دستور زیر را اجرا کنید و در صورت درخواست، شاخهای را برای rollout انتخاب کنید:
firebase apphosting:rollouts:create BACKEND_ID
به طور جایگزین، میتوانید با استفاده از گزینه --git-branch انتشار آخرین کامیت برای یک شاخه خاص را آغاز کنید:
firebase apphosting:rollouts:create BACKEND_ID
--git_branch BRANCH_NAME
همچنین میتوانید با استفاده از گزینه --git-commit یک rollout با یک commit خاص ایجاد کنید:
firebase apphosting:rollouts:create BACKEND_ID
--git_commit COMMIT_ID
بازیابی یک انتشار قبلی
App Hosting دو گزینه برای بازیابی نسخه قبلی ارائه میدهد:
- فوراً و بدون نیاز به بازسازی به حالت قبل برگردید
- بازسازی و بازگشت به نسخه قبلی
ایجاد یک بازگشت فوری
گاهی اوقات ممکن است لازم باشد به سرعت به نسخه قدیمیتر برنامه خود برگردید - برای مثال، اگر در یک نسخه جدید، یک اشکال اساسی پیدا کردهاید یا با یک نسخه ناپایدار مواجه هستید که مانع از انتشار نسخههای جدید میشود. در چنین مواردی، میتوانید یک تصویر کانتینر موجود را به انتخاب خود از یک نسخه قبلی بازیابی کنید. این تصویر بازسازی نمیشود، بلکه از کد و پیکربندی محیط از زمان ساخت اولیه استفاده میکند.
برای ایجاد یک بازگشت فوری:
- در کنسول Firebase ، به Hosting & Serverless > App Hosting بروید.
- برای بکاندی که میخواهید برای آن عقبگرد ایجاد کنید، روی «مشاهده» کلیک کنید.
- برگه Rollouts را انتخاب کنید.
- در جدول تاریخچه برای بخش مدیریت، منوی سه نقطهای را برای نسخه قبلی انتخاب کنید.
- گزینهی «بازگشت به این نسخه» را انتخاب کرده و تأیید کنید.
بازسازی و بازگشت به عقب
اگر میخواهید به نسخه قدیمیتر برنامه خود برگردید اما همچنان پیکربندی فعلی را حفظ کنید، میتوانید برنامه را به عنوان بخشی از فرآیند بازگرداندن به نسخه قبلی، بازسازی کنید. به عنوان مثال، اگر آخرین نسخه شما مقدار کلید API را در Secret Manager بهروزرسانی کرده باشد، بازسازی میتواند تضمین کند که کلید جدید پس از بازگرداندن به نسخه قبلی در برنامه شما استفاده میشود.
برای بازسازی و بازگشت به حالت اولیه:
- در کنسول Firebase ، به Hosting & Serverless > App Hosting بروید.
- برای ایجاد یک عقبگرد، روی «مشاهده داشبورد» در قسمت مدیریت سایتی که میخواهید برای آن عقبگرد ایجاد کنید، کلیک کنید.
- برگه Rollouts را انتخاب کنید.
- گزینه Create را انتخاب کنید.
- در پنجرهی «ایجاد یک نسخه» ، گزینهی «Oarly commit» را انتخاب کنید و سپس شناسهی نسخهای را که میخواهید بازسازی کنید و به آن برگردید، وارد کنید. شناسهی نسخه، بخشی از «جزئیات تغییر» برای هر نسخه است که در تاریخچهی نسخههای شما فهرست شده و در داخل پرانتز در برچسب قرار دارد.
- برای شروع بازگرداندن، ایجاد را انتخاب کنید.
تنظیمات انتشار را تغییر دهید
شما میتوانید شاخهی زندهی انتشار را تغییر دهید و انتشار خودکار را با استفاده از کنترلهای موجود در نمای تنظیمات > استقرار در داشبورد برای یک backend غیرفعال یا فعال کنید.
- در کنسول Firebase ، به Hosting & Serverless > App Hosting بروید.
- برای قسمت پشتی که میخواهید تنظیمات مربوط به بهروزرسانی را در آن انجام دهید، روی «مشاهده» کلیک کنید.
- در داشبورد بخش مدیریت، تنظیمات را انتخاب کنید. نمای پیشفرض، اطلاعات مربوط به دامنهها و دامنههای سفارشی را نمایش میدهد.
- نمای Deployment را انتخاب کنید. در این نما، میتوانید شاخهی زنده را برای rolloutها تغییر دهید و rolloutهای خودکار را غیرفعال یا فعال کنید. همچنین، گزینههایی برای تنظیم دایرکتوری ریشهی برنامه و محیط backend وجود دارد (به Deploy to multiple environments مراجعه کنید).
مدیریت انتشار خودکار
به طور پیشفرض، App Hosting یک لیست «الزامی» از تمام فایلها را در نظر میگیرد، به این معنی که هر کامیت جدید به مخزن شما، یک ساخت و انتشار جدید را آغاز میکند. با این حال، برای صرفهجویی در زمان و جلوگیری از استقرارهای غیرضروری، میتوانید App Hosting طوری پیکربندی کنید که بر اساس مسیرهای فایل خاص اصلاحشده در یک کامیت، از ساختها صرفنظر کند.
میتوانید این مورد را در بخش تنظیمات > پیادهسازیها > محرکهای پیادهسازی پیکربندی کنید. در اینجا، اگر میخواهید هر کامیت جدید به مخزن شما باعث ایجاد یک ساخت و پیادهسازی جدید شود، میتوانید مسیرهای مورد نیاز را خالی بگذارید، یا میتوانید دقیقاً مشخص کنید که کدام دایرکتوریها یا فایلها باید همیشه یک پیادهسازی را ایجاد کنند. اگر دایرکتوریها را مشخص میکنید، حتماً تمام مسیرهایی را که تغییرات باید در آنها پیادهسازی را ایجاد کنند، اضافه کنید.
دایرکتوریها یا فایلهایی که به مسیرهای نادیده گرفته شده اضافه میکنید، هرگز به طور خودکار فعال نمیشوند. در مواردی که یک زیرشاخه در هر دو لیست ضروری و نادیده گرفته شده قرار گیرد، فعال نمیشود . اگر فقط لیست مسیرهای نادیده گرفته شده را پر کنید، App Hosting به طور خودکار "*" را برای مسیرهای ضروری پر میکند.
اگر کامیتی را ارسال کنید که هیچ یک از فایلهای تغییر یافته با مسیرهای مورد نیاز شما مطابقت نداشته باشند (یا اگر همه تغییرات به صراحت توسط مسیرهای نادیده گرفته شده شما حذف شوند)، App Hosting همچنان دریافت رویداد GitHub را تأیید میکند، اما حالتهای ساخت و راهاندازی را به عنوان SKIPPED علامتگذاری میکند و هیچ راهاندازی خودکاری آغاز نمیشود.