التكامل والنشر المستمران: المبادئ، خط المعالجة، البيئات

الهدف

فهم لماذا تُؤتمت الفرق اختباراتها وعمليات وضع التطبيقات في الإنتاج، وما الذي تعنيه بالضبط الاختصارات CI وCD، وكيف يُقسَّم خط المعالجة (pipeline)، وما فائدة البيئات (environments). ستكتب بعد ذلك أول pipeline لك… بلغة shell بسيطة، لترى بوضوح ما تُؤتمته أداة مثل GitHub Actions أو GitLab CI.

أهم النقاط

• التكامل المستمر (CI): كل تعديل يُدفع (push) يُبنى ويُختبر تلقائيًا، عدة مرات في اليوم، لاكتشاف المشاكل فورًا.
• التسليم المستمر (continuous delivery): كل نسخة تجتاز الـ CI تكون جاهزة للانتقال إلى الإنتاج؛ ويبقى الوضع في الإنتاج نقرة بشرية.
• النشر المستمر (continuous deployment): كل نسخة تجتاز جميع الفحوص تنتقل تلقائيًا إلى الإنتاج.
• يسلسل الـ pipeline مجموعة من المراحل (lint، الاختبارات، build، النشر)؛ وأول مرحلة تفشل توقف كل شيء.
• تسمح البيئات (التطوير، القبول/staging، الإنتاج) بالتحقق من نسخة قبل أن تصل إلى الزبائن.
• المبدأ المحوري: نبني مرة واحدة فقط وننشر الأثر نفسه (artifact) في كل مكان.

1. المشكلة: « إنه يعمل على جهازي »

في وكالة Atlas Web (الدار البيضاء)، قبل الأتمتة، كان الوضع في الإنتاج يبدو هكذا:

• مساء الجمعة، يدمج يوسف ثلاثة أسابيع من عمل أربعة أشخاص؛
• لم يشغّل أحد جميع الاختبارات: بعضها لم يعد ينجح منذ عشرة أيام؛
• يبني الموقع على جهازه هو (بنسخة Node.js الخاصة به)، ثم ينسخ الملفات عبر FTP إلى الخادم؛
• يتعطّل موقع أحد الزبائن يوم السبت؛ ولا أحد يعرف أي تعديل هو السبب.

يحلّ التكامل والنشر المستمران هذه المشاكل بثلاث أفكار:

2. CI، التسليم المستمر، النشر المستمر

                         Intégration continue (CI)
            ┌──────────────────────────────────────────────┐
  push  →   │ récupérer le code → lint → tests → build      │ → artefact
            └──────────────────────────────────────────────┘
                                                              │
     Livraison continue : déploiement en recette automatique, │
     en production sur décision humaine (bouton)  ────────────┤
                                                              │
     Déploiement continu : tout est automatique jusqu'à la    │
     production, si tous les contrôles sont verts  ───────────┘

عمليًا، كثيرًا ما نقول « CI/CD » للدلالة على المجموع. وكالة مثل Atlas Web تمارس عادةً التسليم المستمر: كل دمج في main ينتقل تلقائيًا إلى بيئة القبول، ويُطلق رئيس المشروع الإنتاج بعد موافقة الزبون.

3. تشريح الـ pipeline

يُقسَّم الـ pipeline إلى مراحل (stages) تحتوي على مهام (jobs). يمكن لمهام المرحلة نفسها أن تعمل بالتوازي؛ أما المراحل فتتوالى بالترتيب.

  étape « vérifier »      étape « tester »        étape « construire »    étape « déployer »
  ┌──────────┐            ┌──────────────┐        ┌──────────────┐        ┌──────────────┐
  │ lint     │            │ tests Node 20│        │ image Docker │        │ recette      │
  │ format   │   ───→     │ tests Node 22│  ───→  │ archive      │  ───→  │ production   │
  └──────────┘            └──────────────┘        └──────────────┘        │ (manuel)     │
                                                                          └──────────────┘

يعمل الـ pipeline على runner (أو المنفّذ): آلة، غالبًا ما تكون آلة افتراضية أو حاوية جديدة، يوفّرها GitHub أو GitLab، أو مثبّتة على خوادمك الخاصة. وبما أنها تنطلق من الصفر في كل مرة، تختفي عبارة « إنه يعمل على جهازي ».

الخصائص الجيدة للـ pipeline

• سريع: أقل من 10 دقائق للنتيجة الرئيسية؛ وبعد ذلك يتوقف المطوّرون عن انتظار النتيجة.
• موثوق: الاختبار الذي يفشل عشوائيًا (flaky) يدمّر الثقة؛ إما أن نصلحه أو نزيله.
• مُدار بالنسخ: الـ pipeline ملف داخل المستودع (.github/workflows/*.yml، .gitlab-ci.yml)، يُراجَع في pull request مثل الشيفرة.
• الأحمر = أولوية: عندما يكون main معطّلًا، يصلحه الفريق قبل المواصلة.

4. البيئات

قواعد تجنّب الكوارث:

• الأثر نفسه ينتقل من القبول إلى الإنتاج: لا نعيد البناء بينهما، وإلا فإن ما تحقّقنا منه ليس هو ما ننشره.
• وحده الإعداد (configuration) يتغيّر من بيئة إلى أخرى (عنوان قاعدة البيانات، مفاتيح API)، عبر متغيّرات وأسرار خاصة بكل بيئة.
• الإنتاج محمي: النشر محصور في فروع معيّنة، والموافقة إلزامية، والأسرار غير متاحة للمهام الأخرى.
• نعرف دائمًا كيف نتراجع (rollback) إلى النسخة السابقة (الدرس 3.2).

5. مشهد الأدوات

يغطي المستويان 1 و2 من هذا التكوين GitHub Actions ثم GitLab CI. بعد فهم المبادئ، يصبح الانتقال من أداة إلى أخرى مسألة مفردات في الغالب.

6. pipeline يدوي، للفهم

قبل أن نعهد بالعمل إلى منصة، لنكتب التسلسل نفسه بلغة shell. هذا بالضبط ما سيفعله الـ runner: أوامر، بالترتيب، مع التوقف عند أول خطأ.

#!/bin/sh
# scripts/pipeline.sh — pipeline محلي لواجهة Atlas
set -e                      # التوقف عند أول أمر يفشل

echo "== lint"
npm run lint

echo "== tests"
npm test

echo "== build"
mkdir -p dist
tar -czf dist/vitrine.tar.gz package.json src
echo "Artefact prêt : dist/vitrine.tar.gz"

chmod +x scripts/pipeline.sh
./scripts/pipeline.sh
echo "code : $?"            # 0 = pipeline أخضر؛ أي قيمة أخرى = أحمر

set -e هو المفتاح: من دونه، سيواصل السكربت بعد اختبار فاشل وينتج أثرًا معطوبًا. وتطبّق منصات الـ CI القاعدة نفسها: الأمر الذي يُرجع رمزًا غير صفري يُفشل المهمة.

يمكنك حتى ربط هذا الـ pipeline بـ Git بواسطة hook من نوع pre-push (تكوين Git، الدرس 3.2): يُرفض الـ push إذا فشل الـ pipeline. هذا مفيد، لكنه يبقى على جهازك ويمكن تجاوزه بـ --no-verify. أما الـ CI الحقيقي فيعمل على الخادم، للجميع، عند كل push.

7. القياس: المؤشرات الأربعة

لمعرفة ما إذا كانت سلسلتك تتحسّن، كثيرًا ما تتابع الفرق أربعة مؤشرات (تُسمّى « DORA »):

الـ CI/CD الجيد يرفع المؤشرين الأولين ويخفض المؤشرين الأخيرين في الوقت نفسه: نُسلّم أكثر وبأمان أكبر، لأن كل تسليم صغير.

8. من أين نبدأ في فريق قائم

لا داعي لأتمتة كل شيء دفعة واحدة. هذه هي الخطة التي اتبعتها Atlas Web، على مدى شهر تقريبًا:

بعد ذلك فقط يأتي التحسين (التخزين المؤقت cache، التوازي)، والأمن المتقدّم (OIDC، التوقيعات، المستوى 4)، وإذا رغب الفريق، النشر المستمر الكامل.

نصيحتان لإنجاح هذا الانتقال:

• قِس قبل وبعد: متوسط مدة الوضع في الإنتاج، وعدد الحوادث في الشهر. هذه الأرقام تُقنع أكثر من أي خطاب.
• حافظ على pipeline بسيط ومقروء: ملف YAML يفهمه الفريق كله أفضل من آلة معقّدة لا يعرف إصلاحها إلا شخص واحد.

أخطاء متكررة

• أتمتة الفوضى: دون اختبارات مؤتمتة، لا يفعل الـ pipeline سوى نشر الأخطاء بسرعة أكبر. ابدأ ببعض الاختبارات على الدوال الحرجة (حساب الأسعار، الدفع).
• إعادة البناء للإنتاج لما تمّ التحقق منه في بيئة القبول: لم يعد الأثر نفسه.
• pipeline مدّته 40 دقيقة: يقلّ دفع المطوّرين للشيفرة ويتجاوزون الـ CI. وزّع العمل بالتوازي، واستعمل التخزين المؤقت (الدرس 1.3).
• تجاهل pipeline أحمر « لأن هذا الاختبار يفشل دائمًا »: أصلحه أو احذفه، لكن لا تعتد على اللون الأحمر.

التطبيق العملي (Lab)

في مشروع Node.js /root/vitrine (الموجود مسبقًا في Git، مع اختبار وlint)، تبني pipeline محليًا:

1. scripts/pipeline.sh: lint ثم الاختبارات، مع التوقف عند أول خطأ؛
2. مرحلة build تُنتج الأثر dist/vitrine.tar.gz، فقط إذا كان كل شيء أخضر؛
3. commit للسكربت، دون الأثر؛
4. hook من نوع pre-push يشغّل الـ pipeline قبل كل push.

تُعطّل عمليات التحقق اختبارًا عمدًا في نسخة من المشروع للتأكد من أن الـ pipeline الخاص بك يصبح أحمر فعلًا.

اختبار قصير

1. ما الفرق بين التسليم المستمر والنشر المستمر؟
2. لماذا يتوقف الـ pipeline عند أول مرحلة فاشلة؟
3. ما هو الـ runner، ولماذا ينطلق من آلة جديدة؟
4. لماذا يجب أن ننشر في الإنتاج الأثر نفسه الذي تمّ التحقق منه في بيئة القبول؟
5. ماذا يفعل set -e في سكربت pipeline؟

المراجع: GitHub Docs (CC BY 4.0) وGitLab Docs (CC BY-SA 4.0). نص أصلي من MasterLinux.