دراسة حالة

من دفعة git إلى الإنتاج — دون خوف

تطبيق حقيقي يعمل على Managed Containers، متصل بمستودع GitHub. كل دفعة (push) إلى main تُبنى وتُنشر تلقائيًا — لكن إلى نسخة Staging، وليس إلى الإنتاج مباشرة أبدًا. عندما يبدو كل شيء صحيحًا، تُنشر تلك البنية بالتحديد إلى الإنتاج بنقرة واحدة. لا أخطاء 504 أثناء البناء، ولا عمليات نشر «على أمل أن تعمل». راجع دليلي خط الأنابيب النشري والنشر من Git لمعرفة كيفية القيام بذلك.

← العودة إلى مساعدة المنصة

1. اربط المستودع مرة واحدة — يظهر خط الأنابيب

التطبيق المثال هو تطبيق ويب صغير لشجرة العائلة (خدمة Node خلف حاوية). ربط مستودع GitHub الخاص به هو الإعداد بأكمله:

في Platforms → Container Apps، اربط GitHub واختر المستودع والفرع (main).
هذا يحول التطبيق إلى خط أنابيب نشري (Deployment pipeline): بيئة Staging (نسخة اختبار على رابط ca-*.cdn.com.tr خاص بها) وProduction، مع زر ترقية (Promote) بينهما.
من الآن فصاعدًا، كل دفعة تُنشر تلقائيًا إلى Staging — لن تلمس الإنتاج أبدًا بمجرد دفع الكود.

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

2. كل دفعة تصل إلى Staging — الإنتاج يستمر في الخدمة

إليك نفس التطبيق في كلتا البيئتين في اللحظة نفسها. انظر إلى ختم البناء (build stamp) في التذييل: لدى Staging بالفعل البنية الأحدث من آخر دفعة، بينما لا يزال Production يقدّم البنية السابقة. لم يُعَد بناء أي شيء في تطبيق الإنتاج، لذا لم يكن هناك أي توقف ولا أي أخطاء 504 أثناء تجميع البنية الجديدة.

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 — ويمكن الوصول إليها على رابط اختبارها الخاص.
Production لم يُمس: نفس البنية قيد التشغيل، نفس النطاق الحي، دون انقطاع.
تختبر البنية الجديدة في بيئة حقيقية ومعزولة قبل أن يراها أي مستخدم إنتاج واحد.

3. تحقق على رابط Staging الحقيقي

Staging نسخة حقيقية قيد التشغيل من التطبيق على نطاقها الفرعي الخاص — نفس الصورة، نفس الإضافات — لذا يمكنك تجربة التغيير الفعلي بالنقر خلاله، لا محاكاة له. لا تنتقل للخطوة التالية إلا عندما يكون كل شيء صحيحًا.

افتح رابط اختبار Staging من بطاقة خط الأنابيب وجرّب التغيير من البداية للنهاية.
كسرت شيئًا؟ فقط ادفع إصلاحًا — تُعاد نشر Staging، وProduction لا يزال آمنًا.

4. الترقية (Promote): نقرة واحدة، بلا إعادة بناء

لا تقوم الترقية (Promote) ببناء أي شيء. إنها تبدّل مصدر (origin) نطاق الإنتاج إلى بنية Staging التي تعمل بالفعل — تبديل فوري وذري (atomic). البنية التي اختبرتها هي نفسها حرفيًا، بايتًا بايت، البنية التي تصبح مباشرة (live).

انقر على الترقية (Promote) على بطاقة خط الأنابيب — يقدّم الإنتاج الآن البنية بالتحديد التي تحققت منها على Staging.
لأنه تبديل لمصدر النطاق (وليس إعادة بناء)، يكون التحويل فوريًا ودون أي توقف.
التراجع (Rollback) هو نفس العملية بالعكس: نقرة واحدة تعيد الإنتاج إلى البنية السابقة (مع لقطة قاعدة بيانات إن كانت متوفرة للتطبيق).

نفس خط الأنابيب من الطرفية (cdnctl)

كل ما سبق قابل للبرمجة النصية (scriptable) — مفيد لـ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>

لماذا هذا آمن بحكم التصميم

دفع الكود لا يمكن أن يكسر الإنتاج أبدًا — النشر التلقائي يستهدف Staging فقط.
ما ترقّيه هو بالضبط ما اختبرته (لا إعادة بناء بين الاختبار والمباشر).
التحويل والتراجع هما تبديلا مصدر نطاق فوريان، وليسا عمليات إعادة نشر بطيئة.
تحدث عمليات البناء على الهامش، فلا يُرجع الموقع المباشر أبدًا خطأ 504 أثناء التجميع.

أدلة مرجعية: خط الأنابيب النشري · النشر من Git · بيئات Blue/green.