مطالعه موردی

از یک git push تا production — بدون ترس

یک اپلیکیشن واقعی که روی Managed Containers اجرا می‌شود و به یک مخزن گیت‌هاب متصل است. هر push به main به‌طور خودکار ساخته و مستقر می‌شود — اما نه مستقیم به production، بلکه به یک نسخه Staging. وقتی درست به‌نظر رسید، با یک کلیک همان build دقیقاً به‌صورت زنده منتشر می‌شود. نه خطای ۵۰۴ حین build، نه استقرارهای «امیدوارم کار کند». برای نحوه انجام آن به راهنماهای خط لوله استقرار و Deploy from Git مراجعه کنید.

← بازگشت به راهنمای پلتفرم

۱. یک‌بار مخزن را متصل کنید — خط لوله خودش ظاهر می‌شود

اپلیکیشن نمونه یک وب‌اپ کوچک شجره‌نامه است (یک سرویس Node پشت یک کانتینر). تمام راه‌اندازی، فقط اتصال مخزن گیت‌هاب آن است:

در Platforms → Container Apps، گیت‌هاب را متصل کنید و مخزن و برنچ (main) را انتخاب کنید.
این کار اپلیکیشن را به یک خط لوله استقرار تبدیل می‌کند: یک محیط Staging (نسخه آزمایشی روی URL مخصوص به خودش با الگوی ca-*.cdn.com.tr) و Production، با یک دکمه Promote بین آن‌ها.
از این پس، هر push به‌طور خودکار روی Staging مستقر می‌شود — شما هرگز با push کردن کد به production دست نمی‌زنید.

The Deployment pipeline card: Staging (left, auto-deploys) → Promote → Production (right).

۲. هر push روی Staging می‌نشیند — production همچنان سرویس‌دهی می‌کند

این همان اپلیکیشن است در هر دو محیط، در یک لحظه. به مهر زمانی build در فوتر نگاه کنید: Staging از قبل build جدیدتر از آخرین push را دارد، درحالی‌که Production هنوز نسخه قبلی را سرویس می‌دهد. هیچ چیزی در اپ production دوباره ساخته نشد، پس در طول کامپایل شدن build جدید هیچ قطعی و هیچ ۵۰۴ای رخ نداد.

Staging: build 20260714.1713 (the latest push) — served on its own ca-*.cdn.com.tr test URL.

Production: build 20260714.1518 (the previous build) — still live and uninterrupted.

Staging آخرین commit را به‌طور خودکار ساخته و مستقر کرده — از URL آزمایشی مخصوص به خودش قابل دسترسی است.
Production دست‌نخورده است: همان build در حال اجرا، همان دامنه زنده، بدون وقفه.
build جدید را در یک محیط واقعی و ایزوله تست می‌کنید، پیش از آنکه حتی یک کاربر production آن را ببیند.

۳. روی URL واقعی Staging تأیید کنید

Staging یک نسخه واقعی و در حال اجرا از اپلیکیشن روی ساب‌دامین مخصوص به خودش است — همان ایمیج، همان افزونه‌ها — بنابراین می‌توانید تغییر واقعی را کلیک‌به‌کلیک بررسی کنید، نه یک شبیه‌سازی. فقط وقتی درست بود ادامه می‌دهید.

URL آزمایشی Staging را از کارت خط لوله باز کنید و تغییر را سرتاسر امتحان کنید.
چیزی خراب شد؟ فقط یک اصلاح push کنید — Staging دوباره مستقر می‌شود، Production همچنان امن است.

۴. Promote: یک کلیک، بدون بازساخت

Promote چیزی نمی‌سازد. مبدأ دامنه production را به build در حال اجرای Staging تغییر می‌دهد — یک تعویض آنی و اتمیک. همان buildی که تست کردید، بایت‌به‌بایت همان buildی است که زنده می‌شود.

روی Promote در کارت خط لوله کلیک کنید — production اکنون دقیقاً همان buildی را سرویس می‌دهد که روی Staging تأیید کردید.
چون این یک تعویض مبدأ دامنه است (نه بازساخت)، انتقال آنی و بدون قطعی است.
Rollback هم دقیقاً همان است، برعکس: یک کلیک production را به build قبلی برمی‌گرداند (به همراه یک اسنپ‌شات پایگاه‌داده، اگر اپلیکیشن یکی داشته باشد).

همان خط لوله از ترمینال (cdnctl)

همه موارد بالا قابل اسکریپت‌نویسی است — برای CI مفید. پنل و cdnctl از همان اندپوینت‌ها استفاده می‌کنند:

# Connect once in the panel, then every push to main auto-deploys to Staging.
# Verify Staging on its test URL, then promote the tested build to production:
cdnctl container apps status  --account <uuid> --app <staging_app_uuid>
cdnctl container apps promote --account <uuid> --app <staging_app_uuid>

# Roll back to the previous production build if needed (instant, no rebuild):
cdnctl container apps rollback-promotion --account <uuid> --app <prod_app_uuid>

چرا این طراحی از ابتدا امن است

push کردن کد هرگز نمی‌تواند production را خراب کند — استقرار خودکار فقط Staging را هدف می‌گیرد.
آنچه Promote می‌کنید دقیقاً همان چیزی است که تست کرده‌اید (بین تست و زنده‌سازی هیچ بازسازی‌ای نیست).
انتقال و rollback تعویض‌های آنی مبدأ دامنه هستند، نه استقرارهای مجدد کند.
build ها جدا انجام می‌شوند، پس سایت زنده هرگز حین کامپایل ۵۰۴ برنمی‌گرداند.

راهنماهای مرجع: خط لوله استقرار · Deploy from Git · محیط‌های Blue/green.