CI/CD حقيقي: ابنِ مرة واحدة وانشر النسخة التي اختبرتها

القرار المباشر: ابن نسخة واحدة غير متغيرة لكل Commit، اختبرها وسجل Digest ثم رقّ النسخة نفسها بين البيئات. وثق مهام النشر عبر OIDC مقيد وضع الإنتاج خلف حماية البيئة.

هذه المقالة لا تقدم مزوداً فائزاً لكل الحالات ولا رقماً سحرياً للسعة أو التكلفة. تقدم طريقة قابلة للمراجعة، ثم تطلب قياسها على عبء العمل الحقيقي. راجعت المصادر الرسمية في 2026-08-28، وأي مقارنة مع Google Cloud هنا مبنية على الوثائق وليست ادعاء خبرة تشغيل مباشرة.

القرار في دقيقة

• ينشئ CI النسخة وأدلتها، وينشر CD النسخة المحددة ولا يعيد البناء بصمت من تبعيات متحركة.
• ثبت Actions والتبعيات وقلل صلاحيات GITHUB_TOKEN وامنع كود Pull Request غير الموثوق من الوصول لبيانات النشر.
• اربط ثقة السحابة بمستودع وفرع أو بيئة محمية بدلاً من قبول كل رمز من المؤسسة.
• نفذ ترحيلاً متوافقاً للخلف قبل الحركة عند الإمكان وأجل الحذف المدمر حتى خروج الكود القديم.
• عرّف الرجوع كقرار قابل للتنفيذ للنسخة والبيانات، لا كسطر في Runbook.

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

الأداة القابلة لإعادة الاستخدام

البند	القرار
البناء	Commit SHA إلى Artifact Digest
التحقق	Unit وIntegration وفحص ومنشأ
التجربة	نفس Digest مع Smoke وترحيل
الموافقة	بيئة محمية ومراجع مستقل
الإنتاج	نفس Digest مع Canary وبوابة صحة
الاستعادة	Digest سابق ورجوع متوافق مع البيانات

ضع هذه المصفوفة داخل قرار المعمارية أو تذكرة التنفيذ. كل صف بلا مالك أو دليل قبول هو خطر مؤجل.

كيف تستخدم الأداة فعلياً

1. البناء

القرار المقترح هنا هو: Commit SHA إلى Artifact Digest. لا تنسخ القيمة بلا سياق. اكتب مصدر المدخل والبيئة التي ينطبق عليها ومالكها وتاريخ مراجعتها. حوّلها إلى فحص يمكن تكراره قبل النشر وبعده، وسجل الحالة الخاطئة التي يجب أن يرفضها النظام. إذا تغيرت البيانات أو المنطقة أو نمط الحركة، افتح القرار من جديد بدلاً من افتراض أن الإعداد القديم ما زال مناسباً.

2. التحقق

القرار المقترح هنا هو: Unit وIntegration وفحص ومنشأ. لا تنسخ القيمة بلا سياق. اكتب مصدر المدخل والبيئة التي ينطبق عليها ومالكها وتاريخ مراجعتها. حوّلها إلى فحص يمكن تكراره قبل النشر وبعده، وسجل الحالة الخاطئة التي يجب أن يرفضها النظام. إذا تغيرت البيانات أو المنطقة أو نمط الحركة، افتح القرار من جديد بدلاً من افتراض أن الإعداد القديم ما زال مناسباً.

3. التجربة

القرار المقترح هنا هو: نفس Digest مع Smoke وترحيل. لا تنسخ القيمة بلا سياق. اكتب مصدر المدخل والبيئة التي ينطبق عليها ومالكها وتاريخ مراجعتها. حوّلها إلى فحص يمكن تكراره قبل النشر وبعده، وسجل الحالة الخاطئة التي يجب أن يرفضها النظام. إذا تغيرت البيانات أو المنطقة أو نمط الحركة، افتح القرار من جديد بدلاً من افتراض أن الإعداد القديم ما زال مناسباً.

4. الموافقة

القرار المقترح هنا هو: بيئة محمية ومراجع مستقل. لا تنسخ القيمة بلا سياق. اكتب مصدر المدخل والبيئة التي ينطبق عليها ومالكها وتاريخ مراجعتها. حوّلها إلى فحص يمكن تكراره قبل النشر وبعده، وسجل الحالة الخاطئة التي يجب أن يرفضها النظام. إذا تغيرت البيانات أو المنطقة أو نمط الحركة، افتح القرار من جديد بدلاً من افتراض أن الإعداد القديم ما زال مناسباً.

5. الإنتاج

القرار المقترح هنا هو: نفس Digest مع Canary وبوابة صحة. لا تنسخ القيمة بلا سياق. اكتب مصدر المدخل والبيئة التي ينطبق عليها ومالكها وتاريخ مراجعتها. حوّلها إلى فحص يمكن تكراره قبل النشر وبعده، وسجل الحالة الخاطئة التي يجب أن يرفضها النظام. إذا تغيرت البيانات أو المنطقة أو نمط الحركة، افتح القرار من جديد بدلاً من افتراض أن الإعداد القديم ما زال مناسباً.

6. الاستعادة

القرار المقترح هنا هو: Digest سابق ورجوع متوافق مع البيانات. لا تنسخ القيمة بلا سياق. اكتب مصدر المدخل والبيئة التي ينطبق عليها ومالكها وتاريخ مراجعتها. حوّلها إلى فحص يمكن تكراره قبل النشر وبعده، وسجل الحالة الخاطئة التي يجب أن يرفضها النظام. إذا تغيرت البيانات أو المنطقة أو نمط الحركة، افتح القرار من جديد بدلاً من افتراض أن الإعداد القديم ما زال مناسباً.

تسلسل التنفيذ

1. ينشئ CI النسخة وأدلتها، وينشر CD النسخة المحددة ولا يعيد البناء بصمت من تبعيات متحركة. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 1 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
2. ثبت Actions والتبعيات وقلل صلاحيات GITHUB_TOKEN وامنع كود Pull Request غير الموثوق من الوصول لبيانات النشر. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 2 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
3. اربط ثقة السحابة بمستودع وفرع أو بيئة محمية بدلاً من قبول كل رمز من المؤسسة. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 3 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
4. نفذ ترحيلاً متوافقاً للخلف قبل الحركة عند الإمكان وأجل الحذف المدمر حتى خروج الكود القديم. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 4 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
5. عرّف الرجوع كقرار قابل للتنفيذ للنسخة والبيانات، لا كسطر في Runbook. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 5 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.

لا تنقل الإعداد يدوياً بين البيئات. ضع السياسة والبنية ومسار النشر تحت التحكم بالإصدار عندما تسمح الخدمة، وافصل سر الإنتاج عن Build. يجب أن يتمكن شخص آخر من إعادة الخطوات من المستودع وRunbook دون معرفة مخفية.

عقد التسليم بين DevOps والمطورين

يبدأ التسليم بطلب قابل للتنفيذ: ما Commit أو Digest المطلوب؟ ما المتغيرات غير السرية؟ ما أسماء الأسرار ومن يملكها دون نسخ قيمها في التذكرة؟ ما فحص الصحة؟ ما الترحيل؟ وما السلوك المقبول عند فشل الاعتماد الخارجي؟ يجب أن يرفق المطور طريقة تشغيل محلية أو في بيئة اختبار، وعينة إعداد آمنة، واختبارات المسارات الحرجة، وأثر التغيير على البيانات والتوافق للخلف.

يعيد مسؤول DevOps عنوان البيئة وحدود الصلاحية ومسار السجلات ولوحة القياس ومدة الاحتفاظ وخطة النشر والرجوع. قبل الموافقة يتفق الطرفان على مسؤول مراقبة الإصدار ومدة نافذة القرار وحد الإحصائي الذي يوقف Canary أو يعيد النسخة. بعد النشر لا تكفي رسالة «تم». أرفق Digest المنشور ووقت النشر ونتيجة Smoke والرابط الفعلي وحالة الترحيل وأي انحراف مقبول مع تذكرة متابعة. هذا العقد يمنع أن يصبح فشل الإعداد مشكلة مجهولة بين فريقين.

أمر أو إعداد للتحقق

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    environment: production
    steps:
      - uses: actions/download-artifact@v5
        with:
          name: app-${{ github.sha }}
      - run: sha256sum --check artifact.sha256
      - run: ./deploy-and-smoke-test.sh

أنماط الفشل التي يجب تصميم الاختبار حولها

إعادة بناء الإنتاج بعد نجاح Staging فتنتج بايتات تبعيات مختلفة.

لا يعتمد هذا القرار قبل تحديد المالك والبيئة وحد النجاح. سجّل الإعداد الفعلي أو Digest أو استعلام السجل الذي يثبته، ثم أضف اختبار فشل متعمداً يوضح أن الضابط يرفض الحالة الخطأ. بهذه الطريقة تتحول النصيحة إلى عقد تشغيل يمكن للمطور ومسؤول DevOps ومراجع الأمان قراءته بالطريقة نفسها.

منح مهمة البناء إدارة السحابة مع أن مهمة النشر وحدها تحتاج الوصول.

لا يعتمد هذا القرار قبل تحديد المالك والبيئة وحد النجاح. سجّل الإعداد الفعلي أو Digest أو استعلام السجل الذي يثبته، ثم أضف اختبار فشل متعمداً يوضح أن الضابط يرفض الحالة الخطأ. بهذه الطريقة تتحول النصيحة إلى عقد تشغيل يمكن للمطور ومسؤول DevOps ومراجع الأمان قراءته بالطريقة نفسها.

رفع Artifact بلا Digest أو احتفاظ أو رابط منشأ.

لا يعتمد هذا القرار قبل تحديد المالك والبيئة وحد النجاح. سجّل الإعداد الفعلي أو Digest أو استعلام السجل الذي يثبته، ثم أضف اختبار فشل متعمداً يوضح أن الضابط يرفض الحالة الخطأ. بهذه الطريقة تتحول النصيحة إلى عقد تشغيل يمكن للمطور ومسؤول DevOps ومراجع الأمان قراءته بالطريقة نفسها.

إرجاع كود التطبيق بعد تغيير Schema غير قابل للعكس.

لا يعتمد هذا القرار قبل تحديد المالك والبيئة وحد النجاح. سجّل الإعداد الفعلي أو Digest أو استعلام السجل الذي يثبته، ثم أضف اختبار فشل متعمداً يوضح أن الضابط يرفض الحالة الخطأ. بهذه الطريقة تتحول النصيحة إلى عقد تشغيل يمكن للمطور ومسؤول DevOps ومراجع الأمان قراءته بالطريقة نفسها.

بوابات الاختبار والنشر

ابن مصفوفة صغيرة تربط كل خطر باختبار ومالك ودليل. اختبر المسار السليم، ثم اختبر الرفض أو الفشل المتوقع. افصل نجاح المصدر عن نجاح البناء، ونجاح البناء عن نشر المزود، ونشر المزود عن استجابة الرابط العام. وفي الأنظمة التي تتعامل مع بيانات أو طوابير، أضف سلامة البيانات وعمر الطابور إلى فحص الصحة.

قبل الإنتاج شغّل الاختبارات الحتمية في CI، واختبارات البيئة والترحيل وSmoke في CD، ثم تحقق من الرحلة الحرجة على الرابط الفعلي. عرّف حد إيقاف تلقائياً لمعدل الخطأ أو p95 أو فشل الاعتماد، واحتفظ بالنسخة السابقة وإجراء استعادة البيانات. النجاح هو دليل يمكن قراءته، لا لون أخضر وحده.

التكلفة دون رقم تسويقي

احسب الحوسبة والتخزين والطلبات ونقل البيانات والسجلات والنسخ الاحتياطية والمفاتيح والدعم والسعة الاحتياطية ووقت المهندس. استخدم أسعار المنطقة الفعلية في يوم القرار، ثم شغّل إنذار ميزانية ومراقبة شذوذ. لا تجعل خفض التكلفة يزيل هامش الفشل أو يطيل RTO بلا موافقة.

أفضل تحسين تكلفة هو حذف مورد لا تحتاجه أو تقليل عمل الأصل بقياس صحيح. أما الحجز أو الالتزام طويل الأجل فيأتي بعد ثبات الحمل. اكتب وحدة القياس لكل بند، ومن يراجعها، وما الذي يحدث إذا تجاوزت الحد.

ملاحظة من التشغيل

الدرس القابل للتعميم هو أن الحالات المختلفة لا تتساوى: الكود في المستودع، والنسخة المبنية، وحالة المزود، واستجابة المتصفح، وسلامة البيانات لكل منها دليل مستقل. كثير من الأعطال تطول لأن الفريق يرى خطوة ناجحة ويفترض أن السلسلة كلها نجحت. احفظ التوقيت والهوية والمسار والإعداد الفعلي قبل توسيع الصلاحية أو تغيير عدة طبقات معاً.

هذه ملاحظة مجهولة لا تكشف عميلاً أو حساباً أو نتيجة رقمية. فائدتها في الإجراء: غيّر شيئاً واحداً قابلاً للرجوع، راقب الإشارة المتوقعة، ثم حدّث الخط الزمني.

الخطوات العملية التالية

1. انسخ الأداة أعلاه واملأها بأرقام النظام ومسؤوليه لا بتوقعات المبيعات.
2. اختر أخطر فرضيتين ونفذ لهما اختبار فشل واستعادة في بيئة غير إنتاجية.
3. سجل القرار والبدائل والتكلفة ودليل القبول وتاريخ المراجعة.
4. اربط هذه المقالة بالمقالات الأخرى في سلسلة DevOps والسحابة واختر الخطوة التالية حسب الفجوة.

إذا كنت تحتاج مراجعة عملية للبنية أو مسار النشر، ابدأ بنطاق صغير عبر خدمة تطوير الويب والتطبيقات يحدد المخاطر والدليل المطلوب قبل أي التزام كبير.

تابع السلسلة

• السابق: ليس كل تطبيق Odoo يتوسع بالطريقة نفسها: العمال وPostgreSQL والملفات والمهام
• التالي: ماذا تختبر في CI وماذا تؤجل إلى CD؟
• قراءة مرتبطة من المكتبة: مقال عملي مكمل لهذا القرار

استخدم الروابط كمسار تعلم، لكن نفذ كل قرار على بيانات النظام الفعلية.

المصادر وتاريخ المراجعة

• GitHub Actions deployment environments
• GitHub Actions OpenID Connect reference
• GitHub Actions secure use reference
• GitHub artifact attestations
• AWS CI/CD litmus test
• Google Cloud Deploy terminology

آخر مراجعة: 2026-08-28. راجع الأسعار والحصص وتوافر الميزات في المنطقة مباشرة قبل التنفيذ.