خط الأنابيب النشري: دفع (push) → Staging، الترقية (Promote) → Production

خط الأنابيب في لمحة

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

• Staging نسخة حقيقية ومنفصلة من تطبيقك لها رابط اختبار <uid>.cdn.com.tr خاص بها — تُقدَّم عبر حافة (edge) CDN تمامًا مثل الإنتاج.
• Production يستمر في تقديم النسخة القديمة دون أي مساس بينما تُبنى Staging وتُنشر. لا يتغير إلا عندما تقوم أنت بالترقية (Promote).
• التراجع (Roll back) متاح دائمًا بعد الترقية — تُستعاد حركة المرور/الصورة ولقطة قاعدة البيانات السابقة للترقية.

1 · اربط مستودعك (مرة واحدة)

في Platforms → Container Apps → App creation → Deploy from Git، اربط GitHub (موصى به — GitHub App بنقرة واحدة، دون رموز تُدار) أو استخدم رابط مستودع + رمز وصول، اختر المستودع والفرع، فعّل "Keep connected — auto-deploy on every push to this branch"، ثم Build & deploy. التفاصيل الكاملة: دليل النشر من Git.

2 · فعّل Staging

على بطاقة خط الأنابيب، انقر على تفعيل بيئة الاختبار (Enable staging). يُنشئ هذا نسخة اختبار من كل تطبيق في المستودع ويوجّه النشر التلقائي إليها — من تلك اللحظة، تنشر عمليات الدفع Staging، وليس Production أبدًا.

• تحصل نسخة الاختبار على رابط اختبار عام خاص بها (<uid>.cdn.com.tr) تلقائيًا. إذا لم يكن لنسخة أُنشئت سابقًا رابط بعد، تعرض البطاقة زر الحصول على رابط الاختبار.
• مشاركة البيانات (ضمن «Data sharing options»، الافتراضي shared): shared — تستخدم Staging نفس قاعدة البيانات/Redis/التخزين الخاصة بالإنتاج (الأفضل لتغييرات الكود/الواجهة)؛ cloned — تحصل Staging على MySQL خاصة بها بنسخة من البيانات (آمن لتغييرات المخطط)؛ isolated — بداية نظيفة.
• قد يُرجع أول فتح لرابط اختبار جديد خطأ 502 لفترة وجيزة بينما يُفعَّل الحافة (edge)/DNS (نحو دقيقة) — هذا طبيعي ويحدث مرة واحدة فقط.

3 · ادفع — Staging تنشر نفسها

• كل دفعة إلى الفرع المتصل تبني الصورة وتطرحها إلى Staging. تعرض البطاقة آخر دفعة (commit + الوقت) وحالة Staging مباشرة.
• افتح رابط الاختبار وتحقق من البنية الجديدة — لا يزال الإنتاج يقدّم النسخة السابقة، دون أي تأثر على الإطلاق.
• أثناء طرح Staging، تظهر حالتها deploying؛ يبقى زر الترقية (Promote) معطلاً حتى تعمل النسخة.

4 · الترقية (Promote) — فعّل النسخة المُختبرة مباشرة

انقر على الترقية (Promote). يبدأ الإنتاج في تقديم النسخة المُختبرة فورًا — دون بناء ودون توقف. تُؤخذ لقطة قاعدة بيانات تلقائية أولاً، بحيث يمكن للتراجع أيضًا التراجع عن تغييرات البيانات. تحت الغطاء، تُستخدم إحدى آليتين:

• نطاقك الخاص مرتبط ← تبديل مصدر (origin) فوري على حافة CDN: يُربط نطاق الإنتاج أولاً بتطبيق Staging، ثم يُفصَل عن النطاق القديم — نقل حركة مرور خالص، خلال ثوانٍ، دون إعادة تشغيل.
• Production على نطاقه الفرعي <uid>.cdn.com.tr ← تُطرح الصورة المبنية والمُختبرة بالفعل على تطبيق الإنتاج بتحديث متجدد (rolling update) بلا فجوة (zero-gap) (يستمر الـpod القديم في الخدمة حتى يصبح الجديد جاهزًا). تبقى الروابط ثابتة: رابط الاختبار هو دائمًا Staging، والرابط المباشر هو دائمًا Production.

تنقل الترقية البنية، لا الإعدادات: متغيرات البيئة والأسرار (secrets) المضبوطة على Staging تبقى في Staging. غيّر إعدادات الإنتاج في تطبيق الإنتاج.

5 · تراجع (Roll back) (إذا احتجت)

• بعد الترقية، يظهر زر تراجع (Roll back) على جانب Production. تعيد نقرة واحدة النسخة السابقة — يُعكس تبديل النطاق (أو تُعاد نشر الصورة السابقة) وتُستعاد لقطة قاعدة البيانات السابقة للترقية.
• التراجع هو نفس عملية الترقية الفورية بلا إعادة بناء.

من المفيد معرفته

• إيقاف خط الأنابيب: «Disable staging» على البطاقة يجعل عمليات الدفع تنشر الإنتاج مباشرة مجددًا (السلوك القديم — قد يسبب توقفًا أثناء النشر). تُحفظ نسخة الاختبار.
• خدمات جديدة: يُحدّث النشر التلقائي الخدمات الحالية؛ الخدمة المُضافة حديثًا إلى ملف compose لا تُضاف تلقائيًا — شغّل Deploy from Git مرة واحدة لإضافتها.
• المشاريع متعددة التطبيقات: يُنشئ تفعيل بيئة الاختبار نسخة اختبار لكل خدمة في المستودع، و«ترقية الكل» تفعّل المجموعة بأكملها مباشرة معًا.
• نسخ اختبار يدوية: يمكن للتطبيقات غير المتصلة بمستودع استخدام نفس آليات staging/promote من لوحة البيئات — راجع دليل بيئات Blue/green ودراسة الحالة.
• سطر الأوامر: نفس العمليات متاحة عبر cdnctl.