CONTAINER APPS · راهنما

خط لوله استقرار: push → Staging، Promote → Production

یک مخزن گیت را یک‌بار متصل کنید و هر push یک کپی Staging از اپلیکیشن شما را مستقر می‌کند — production هرگز با push دست‌خورده نمی‌شود. build جدید را روی URL مخصوص Staging تست می‌کنید، سپس روی Promote کلیک می‌کنید تا دقیقاً همان نسخه تست‌شده زنده شود. اگر چیزی اشتباه به‌نظر رسید، Roll back نسخه قبلی را (به‌همراه اسنپ‌شات پایگاه‌داده) با یک کلیک بازمی‌گرداند. دیگر خبری از قطعی «هر commit، production را دوباره مستقر می‌کند» نیست.

← همه راهنماهای پلتفرم

به چه چیزی نیاز دارید

یک پروژه compose که از قبل با Deploy from Git و با فعال بودن «Keep connected — auto-deploy on every push» مستقر شده. تمام پیش‌نیاز همین است: کارت خط لوله به‌طور خودکار برای هر مخزن متصل در Platforms → Container Apps ظاهر می‌شود.

خط لوله در یک نگاه

git push ──▶ [ STAGING ]  ──  Promote ──▶ [ PRODUCTION ]
              redeploys on           manual, takes the
              every push             tested build live

Staging یک کپی واقعی و جداگانه از اپلیکیشن شما با URL آزمایشی مخصوص به خودش (<uid>.cdn.com.tr) است — دقیقاً مانند production از طریق edge شبکه CDN سرویس‌دهی می‌شود.
Production در حالی که Staging ساخته و مستقر می‌شود، نسخه قدیمی را دست‌نخورده سرویس می‌دهد. فقط زمانی تغییر می‌کند که شما Promote کنید.
Roll back همیشه پس از یک Promote در دسترس است — ترافیک/ایمیج و اسنپ‌شات پایگاه‌داده پیش از promote بازیابی می‌شوند.

کارت خط لوله استقرار: مخزن و برنچ در بالا؛ ستون Staging که با URL آزمایشی خودش به‌طور خودکار مستقر می‌شود؛ دکمه Promote؛ و ستون Production با URL زنده — کارت خط لوله استقرار در Platforms → Container Apps. چپ: Staging (استقرار خودکار، URL آزمایشی). راست: Production (URL زنده). بین آن‌ها: Promote.

۱ · مخزن خود را متصل کنید (یک‌بار)

در Platforms → Container Apps → App creation → Deploy from Git، گیت‌هاب را متصل کنید (توصیه‌شده — GitHub App تک‌کلیکی، بدون نیاز به مدیریت توکن) یا از URL مخزن + توکن دسترسی استفاده کنید، مخزن و برنچ را انتخاب کنید، گزینه «Keep connected — auto-deploy on every push to this branch» را علامت بزنید، سپس Build & deploy. جزئیات کامل: راهنمای Deploy from Git.

پنل Deploy from Git با گیت‌هاب متصل، انتخابگر مخزن، برنچ و چک‌باکس keep-connected برای استقرار خودکار — گیت‌هاب را متصل کنید و مخزن را متصل نگه دارید — همین است که خط لوله را می‌سازد.

۲ · Staging را فعال کنید

روی کارت خط لوله، روی Enable staging کلیک کنید. این کار یک کپی آزمایشی از هر اپ مخزن می‌سازد و استقرار خودکار را به آن هدایت می‌کند — از آن لحظه به بعد، push ها Staging را مستقر می‌کنند، نه Production را.

کپی آزمایشی به‌طور خودکار URL آزمایشی عمومی خودش (<uid>.cdn.com.tr) را دریافت می‌کند. اگر یک کپی که پیش‌تر ساخته شده هنوز URL ندارد، کارت دکمه Get test URL را نشان می‌دهد.
اشتراک‌گذاری داده (زیر «Data sharing options»، پیش‌فرض shared): shared — Staging از همان پایگاه‌داده/Redis/فضای ذخیره‌سازی production استفاده می‌کند (بهترین برای تغییرات کد/رابط کاربری)؛ cloned — Staging یک MySQL مخصوص خودش با کپی داده می‌گیرد (امن برای تغییرات طرح‌واره)؛ isolated — یک شروع تمیز.
اولین باز شدن یک URL آزمایشی تازه ممکن است هنگام فعال‌سازی edge/DNS (حدود یک دقیقه) برای مدت کوتاهی ۵۰۲ برگرداند — طبیعی و یک‌بار مصرف است.

کارت خط لوله پیش از وجود staging: دکمه Enable staging در ستون Staging با گزینه‌های اشتراک‌گذاری داده در زیر آن — اجرای اول: Enable staging کپی آزمایشی را می‌سازد و استقرار خودکار را دوباره به آن هدف‌گذاری می‌کند.

۳ · Push — Staging خودش را مستقر می‌کند

هر push به برنچ متصل ایمیج را می‌سازد و روی Staging منتشر می‌کند. کارت آخرین push (commit + زمان) و وضعیت Staging را به‌صورت زنده نشان می‌دهد.
URL آزمایشی را باز کنید و build جدید را تأیید کنید — production همچنان نسخه قبلی را سرویس می‌دهد، کاملاً بدون تأثیر.
در حین استقرار Staging، وضعیتش deploying نشان داده می‌شود؛ Promote تا زمانی که کپی در حال اجرا شود غیرفعال می‌ماند.

۴ · Promote — نسخه تست‌شده را زنده کنید

روی Promote کلیک کنید. Production بلافاصله شروع به سرویس‌دهی نسخه تست‌شده می‌کند — بدون build و بدون قطعی. ابتدا یک اسنپ‌شات خودکار از پایگاه‌داده گرفته می‌شود، پس یک rollback می‌تواند تغییرات داده را نیز برگرداند. در پس‌زمینه، یکی از این دو مکانیزم استفاده می‌شود:

اگر دامنه خودتان متصل باشد → یک تعویض آنی مبدأ روی edge شبکه CDN: ابتدا دامنه production به اپ staging متصل می‌شود، سپس از اپ قدیمی آزاد می‌شود — یک جابه‌جایی خالص ترافیک، چند ثانیه، بدون ری‌استارت.
اگر Production روی ساب‌دامین خودش <uid>.cdn.com.tr باشد → ایمیج از قبل ساخته‌شده و از قبل تست‌شده با یک به‌روزرسانی نورد بدون‌وقفه روی اپ production می‌رود (pod قدیمی تا وقتی pod جدید آماده شود همچنان سرویس‌دهی می‌کند). URL ها ثابت می‌مانند: URL آزمایشی همیشه Staging است، URL زنده همیشه Production.

Promote build را منتقل می‌کند، نه پیکربندی را: متغیرهای محیطی و secret های تنظیم‌شده روی Staging روی Staging باقی می‌مانند. پیکربندی production را روی اپ production تغییر دهید.

کارت خط لوله با یک build در حال اجرای Staging و دکمه فعال Promote — Staging در حال اجرا و تأییدشده است — Promote دقیقاً همین build را زنده می‌کند.

۵ · بازگردانی (در صورت نیاز)

پس از یک Promote، دکمه Roll back در سمت Production ظاهر می‌شود. یک کلیک نسخه قبلی را بازمی‌گرداند — تعویض دامنه معکوس می‌شود (یا ایمیج قبلی دوباره مستقر می‌شود) و اسنپ‌شات پایگاه‌داده پیش از promote بازیابی می‌شود.
Rollback همان عملیات آنی و بدون-بازساخت Promote است.

خوب است بدانید

خاموش کردن خط لوله: «Disable staging» روی کارت باعث می‌شود push ها دوباره مستقیماً production را مستقر کنند (رفتار قدیمی — ممکن است حین استقرار باعث قطعی شود). کپی آزمایشی نگه داشته می‌شود.
سرویس‌های جدید: استقرار خودکار سرویس‌های موجود را به‌روز می‌کند؛ سرویسی که تازه به فایل compose اضافه شده به‌طور خودکار اضافه نمی‌شود — برای افزودن آن یک‌بار Deploy from Git را اجرا کنید.
پروژه‌های چند-اپلیکیشنی: Enable staging برای هر سرویس مخزن یک کپی آزمایشی می‌سازد، و «Promote all» کل مجموعه را با هم زنده می‌کند.
کپی‌های آزمایشی دستی: اپ‌هایی که به مخزنی متصل نیستند نیز می‌توانند همان مکانیزم staging/promote را از پنل محیط‌ها استفاده کنند — به راهنمای محیط‌های Blue/green و مطالعه موردی مراجعه کنید.
CLI: همین عملیات از طریق cdnctl نیز در دسترس است.