أساسيات التكامل المستمر

لماذا التكامل المستمر؟

18 دقيقة الدرس 1 من 28

لماذا التكامل المستمر؟

قبل كتابة أول ملف YAML لأي pipeline، السؤال الأهم الذي يجب الإجابة عنه هو: لماذا يوجد CI أصلاً؟ الإجابة ليست "لأنه أفضل ممارسة". الإجابة هي نمط فشل هندسي مؤلم وقابل للقياس يُسمى جحيم التكامل (integration hell) — وCI هو الحل المباشر له.

جحيم التكامل: المشكلة الجذرية

تخيّل فريقاً من ثمانية مهندسين يعمل بالتوازي لمدة أسبوعين. كل مهندس يبني فرع ميزة يلمس كوداً مشتركاً: وحدة المصادقة، مخطط قاعدة البيانات، عقود الـ API، وناقل الأحداث. كل فرع، بمعزل عن الآخر، يجتاز جميع الاختبارات المحلية. ثم يأتي يوم الإصدار، ويحاول الفريق دمج كل شيء في main.

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

مصيدة إنتاجية: جحيم التكامل ليس مجرد إزعاج في الجدول الزمني. على نطاق واسع، يصبح خطراً منهجياً. وجدت دراسة Google لإنتاجية المطورين أن المهندسين في الشركات ذات دورات التكامل الطويلة يقضون ما يصل إلى 40% من وقتهم في تعارضات الدمج وإصلاحات التكامل وإعادة العمل — وقت لا يُنتج أي قيمة للعميل. هذه هي الضريبة الخفية لنموذج "افتح فرعاً واحتفظ به".

السبب الجذري بسيط: كلما طالت مدة انقسام فرعين، كان دمجهما أصعب. هذه خاصية رياضية لإدارة الإصدارات. كل commit في كل فرع هو تعارض محتمل مع كل commit في كل فرع آخر. التأجيل يُضاعف المشكلة أسياً لا خطياً.

الدفعات الصغيرة: رؤية تصنيع Lean

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

مُطبَّقاً على البرمجيات: بدلاً من دمج فرع أسبوعين، ادمج تغييراتك في الجذع المشترك مرة على الأقل يومياً. كل تكامل صغير، والفجوة ضيقة، والتعارضات سطحية، وإذا كُسر اختبار فهو يشير مباشرة إلى آخر commit — لا إلى تراكم أسبوعين من تغييرات ثمانية مهندسين.

الفكرة الأساسية: التكامل المستمر هو ممارسة دمج نسخة كل مهندس العاملة في الخط الرئيسي المشترك بشكل متكرر — على الأقل يومياً، وغالباً عدة مرات في اليوم — مقرونة بخطوة تحقق آلية تؤكد أن الخط الرئيسي يبقى سليماً بعد كل دمج. كلمة "المستمر" تعني الدمج المستمر، لا مجرد تشغيل pipeline باستمرار.

حلقة تغذية راجعة CI: قبل وبعد

يُظهر الرسم البياني أدناه الفرق الملموس بين نموذج تكامل الفروع الطويلة ونموذج CI. ادرس زمن تأخر التغذية الراجعة — هذا هو المتغير الأساسي.

الجزء العلوي: الفروع طويلة الأمد تتباعد بصمت؛ يتركّز ألم التكامل في النهاية. الجزء السفلي: يعمل CI على كل commit؛ الأعطال تظهر في دقائق والسياق لا يزال حاضراً.

ما هو CI فعلاً (وما ليس CI)

المصطلح يُساء استخدامه على نطاق واسع. للـ CI تعريف تقني دقيق بثلاثة مكونات إلزامية:

تكامل متكرر في الخط الرئيسي المشترك. كل مهندس يدفع إلى main (أو فرع قصير الأمد يُدمج خلال يوم) عدة مرات يومياً. الفروع طويلة الأمد تنتهك CI صراحةً — تشغيل pipeline على فرع أسبوعين ليس CI، بل اختبار آلي على فرع معزول.
بناء آلي يُطلَق عند كل push. يُجمّع النظام (إن انطبق)، ويحل التبعيات، ويُنتج حزمة بشكل حتمي. "يعمل على جهازي" يُزال لأن البناء يعمل في بيئة نظيفة وقابلة للتكرار في كل مرة.
مجموعة اختبارات آلية تُعطي إشارة PASS/FAIL حاسمة. يجب أن يكون البناء قابلاً للتحقق. بدون اختبارات آلية، "التكامل المستمر" مجرد دمج مستمر بدون بوابة جودة — أنت تدمج كوداً لا تتحقق منه.

ممارسة احترافية: القاعدة الكلاسيكية في CI في شركات كـ Google وMeta وNetflix هي: لا تنصرف على بناء أحمر. إن كسر commit الخاص بك CI، إما تصلحه فوراً أو تتراجع عنه. يجب أن يكون فرع main دائماً في حالة قابلة للنشر. يُفرض هذا اجتماعياً وتقنياً — قواعد حماية الفروع في GitHub، وطوابير الدمج، وDiff Stacks في Phabricator — كلها موجودة لجعل دمج commit مكسور أمراً مستحيلاً ميكانيكياً لا مجرد أمر مثبَّط.

حلقة التغذية الراجعة: السرعة هي كل شيء

قيمة CI ليست فقط في إيجاد الأخطاء — بل في سرعة التغذية الراجعة. تكلفة إصلاح عيب تنمو أسياً مع الوقت بين الإدخال والاكتشاف:

خطأ يكتشفه المؤلف ثوانٍ بعد كتابته (خطأ تجميع، تحذير linter): يكلف ثوانٍ للإصلاح.
خطأ يُكشف في CI دقائق بعد push: يكلف دقائق للإصلاح، السياق لا يزال حاضراً.
خطأ يُكشف في دورة QA اليدوية أياماً لاحقاً: يكلف ساعات للإصلاح، ويستلزم إعادة بناء السياق.
خطأ يُكشف في الإنتاج أسابيع بعد الدمج: يكلف أياماً، ويستلزم الاستجابة للحوادث والتحليل اللاحق وتواصل العملاء وإصلاح البيانات المحتمل.

pipeline CI يعمل في 8 دقائق أكثر قيمة بكثير من واحد يعمل في 45 دقيقة. المهندسون لن ينتظروا 45 دقيقة للتغذية الراجعة — سيتحولون إلى مهمة أخرى، وحين تصل النتيجة يكون النموذج الذهني قد اختفى. نظام CI الداخلي لـ Google للـ monorepo (المبني على Blaze/Bazel، المُكشوف للعالم كـ Bazel) مصمم للحفاظ على تشغيلات الاختبار ما قبل الإرسال تحت 5 دقائق للحالة الشائعة، مع التخزين المؤقت والتنفيذ البعيد على نطاق عالمي.

أبسط pipeline CI عملي

إليك نقطة بداية على مستوى الإنتاج لخدمة Node.js. تُظهر المكونات الثلاثة الإلزامية: مُحفّز آلي، بناء قابل للتكرار، وبوابة اختبار.

# .github/workflows/ci.yml
# يعمل على كل push إلى main وعلى كل pull request يستهدف main.
# المهمة: تثبيت تبعيات قابل للتكرار، lint، اختبار، بناء.
# الدمج إلى main محجوب بواسطة branch protection في GitHub إن فشل هذا.

name: CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build-and-test:
    runs-on: ubuntu-24.04
    # تثبيت على إصدار محدد من نظام التشغيل للـ runner لضمان قابلية التكرار.

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node 22
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"
          # npm cache مرتبط بـ package-lock.json — إصابة الكاش تتخطى تنزيل npm ci.

      - name: Install dependencies (clean install, locked versions)
        run: npm ci
        # npm ci (لا npm install) — يحترم lockfile تماماً، يفشل إن كان قديماً.

      - name: Lint (ESLint + Prettier)
        run: npm run lint

      - name: Unit and integration tests
        run: npm test -- --ci --coverage --reporters=default --reporters=jest-junit
        env:
          CI: "true"
          # علامة --ci تعطل الوضع التفاعلي وتفشل عند تعارضات الـ snapshot.

      - name: Build production bundle
        run: npm run build
        # يتحقق من أن الحزمة يمكن إنتاجها، لا فقط أن الاختبارات تنجح.

كل قرار هنا مقصود. npm ci بدلاً من npm install يضمن احترام lockfile ويفشل بصوت عالٍ إن كان غير متزامن مع package.json. تثبيت إصدار نظام التشغيل للـ runner يمنع الأعطال الصامتة حين تُطلق GitHub صورة افتراضية جديدة. علامة --ci على Jest تمنع المطالبات التفاعلية من تعليق الـ runner.

فرض CI على مستوى المستودع

pipeline CI يمكن تجاوزه ليس بوابة جودة — بل هو اقتراح. يجب فرض CI الإنتاجي على مستوى المستودع، لا بالاتفاق فحسب.

# GitHub repository ruleset — يفرض CI قبل الدمج (يُضبط في GitHub UI أو عبر API)
# مكافئ استدعاء REST API لتهيئة branch protection برمجياً:

curl -X PUT \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/ORG/REPO/branches/main/protection \
  -d '{
    "required_status_checks": {
      "strict": true,
      "contexts": ["build-and-test"]
    },
    "enforce_admins": true,
    "required_pull_request_reviews": {
      "required_approving_review_count": 1
    },
    "restrictions": null
  }'

# "strict": true تعني أن الفرع يجب أن يكون محدثاً مع main قبل الدمج.
# يمنع هذا فئة أعطال "يعمل على فرعي لكن لا بعد الدمج".
# "enforce_admins": true تعني حتى مدراء المستودع لا يمكنهم تجاوز البوابة.

الفكرة الأساسية: CI ليس أداة تُثبّتها. إنه عقد اجتماعي مُفرَض ميكانيكياً. يوجد الـ pipeline لحماية الخط الرئيسي المشترك نيابة عن الفريق كاملاً. كل مهندس يتجاوزه — حتى "مرة واحدة فقط" — يُضعف العقد. قواعد حماية الفروع تترجم الاتفاق الاجتماعي إلى قيد تقني تُفرضه المنصة نيابة عنك.

الحجة التجارية: ما تُظهره البيانات

بحث Accelerate (Forsgren، Humble، Kim — ست سنوات من بيانات مسح DORA لحالة DevOps، آلاف المؤسسات) وجد رابطاً سببياً مباشراً بين اعتماد CI وأربعة مقاييس تسليم رئيسية. تُظهر المؤسسات ذات ممارسات CI الناضجة:

46 ضعفاً نشرات أكثر تكراراً مقارنة بنظيراتها الأدنى أداءً.
440 ضعفاً زمن قيادة أسرع من commit إلى الإنتاج (ساعات مقابل أسابيع).
5 أضعاف معدل فشل تغيير أقل — حوادث إنتاج أقل لكل نشر.
170 ضعفاً متوسط وقت استعادة أسرع من حوادث الإنتاج.

هذه ليست تحسينات مستقلة. تتضاعف: التكامل المتكرر يكشف العيوب مبكراً، مما يقلل معدل فشل التغيير، مما يقلل حجم الحوادث، مما يُحرّر المهندسين للشحن أكثر، مما يجعل التكامل أسرع. CI هو العجلة الدوّارة التي تُحرّك النظام بأكمله.

من أين تبدأ: إن لم يكن لفريقك CI اليوم، لا تنتظر الـ pipeline المثالي. أنشئ workflow واحداً في GitHub Actions يُشغّل npm test (أو ما يعادله) على كل pull request — حتى لو كانت مجموعة الاختبارات نحيلة. العادة الثقافية لـ "الدمج في خط رئيسي موثَّق" أكثر قيمة من pipeline متطور بدون تبنٍّ. حسِّن الـ pipeline تدريجياً؛ ابنِ العادة أولاً.

ما القادم في هذا الدرس التعليمي

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

الدرس 2 — تشريح pipeline CI: المراحل والوظائف والـ runners والحزم وكيفية ارتباطها.
الدرس 3 — أتمتة البناء وقابلية التكرار: تثبيت التبعيات، مصفوفات البناء، البنيات الحتمية.
الدرس 4 — استراتيجية الاختبار في CI: ماذا تختبر في كل مرحلة، حدود التغطية، موازنة الاختبارات.
الدرس 5 — التحليل الساكن وبوابات الجودة: linters، SAST، فحص التبعيات، وكيفية الفشل بأمان.

بنهاية هذا الدرس التعليمي ستكون قادراً على تصميم وتنفيذ وتشغيل pipeline CI على مستوى الإنتاج لأي تقنية — من monolith إلى monorepo من microservices.