CI/CD CircleCI وCoveralls

إعداد التكامل المستمر والنشر المستمر باستخدام CircleCI وCoveralls: دليل عملي شامل للمطورين

مقدمة

أحدثت منهجيات التطوير الحديثة‑مثل DevOps وإدارة دورة حياة البرمجيات الرشيقة‑تحولًا جذريًا في طريقة بناء التطبيقات ونشرها. في قلب هذا التحول برز مفهوم التكامل المستمر (CI) والنشر المستمر (CD) باعتبارهما حجر الأساس لضمان جودة الشيفرة، وتسريع دورة الإصدار، وتقليص الأخطاء الناتجة عن التحديثات اليدوية. يزداد الاعتماد على خدمات الحوسبة السحابية التي توفر خطوط أنابيب تلقائية تؤدي مهام البناء والاختبار والتوزيع دون تدخل بشري يُذكر. من بين تلك الخدمات تحتل CircleCI مكانة متقدمة بفضل سهولة إعدادها، ونظام الحوسبة المرن القائم على الحاويات، ودعمها الواسع للغات وأُطر العمل المختلفة. يكتمل المشهد مع أداة قياس تغطية الاختبارات Coveralls التي تُتيح تتبّع نسبة الشيفرة المُغطاة بالاختبارات تلقائيًا بعد كل عملية دمج، ما يُضفي طبقة إضافية من الثقة على مسار التطوير.

هذا المقال يُقدّم دليلًا تفصيليًا‑خطوة بخطوة‑لبناء خط أنابيب تكامل ونشر مستمر يُدمج CircleCI مع Coveralls، انطلاقًا من التحضيرات المبدئية وحتى نشر التطبيق في بيئة الإنتاج. يُركّز المقال على جوانب عملية موسَّعة: إعداد المستودع، كتابة ملف تهيئة CircleCI، إدارة الأسرار، القياس الآلي لجودة الشيفرة، تصميم مراحل النشر، واستراتيجيات تحسين الأداء وتقليل التكاليف السحابية. كما يُرفق جدولًا يلخّص الفوارق بين خطط CircleCI السحابية، ويعرض الاعتبارات الأمنية المرتبطة بنقل بيانات التغطية إلى Coveralls. بنهاية المقال يكون القارئ قادرًا على تصميم وتنفيذ بنية CI/CD عالية الاعتمادية، قابلة للتطوير، وملائمة لمشروعات المؤسسات الناشئة والشركات على السواء.

1. مفاهيم أساسية: من التكامل إلى التوصيل

1‑1 التكامل المستمر (CI)

يتمثّل التكامل المستمر في إدماج تغييرات الشيفرة في الفرع الرئيس بصفة متكررة‑عدة مرات يوميًا‑مع فرض تشغيل البطاريات الاختبارية الآلية تلقائيًا عند كل دمج. يحقق ذلك:

• الكشف المبكر عن العطب البرمجي وسرعة المعالجة.

• تقليص صدمات الدمج merge shocks الناجمة عن تباعد الفروع.

• توفير مقياس صحة لحظي للمشروع قابل للمراقبة.

1‑2 التسليم المستمر (Continuous Delivery)

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

1‑3 النشر المستمر (Continuous Deployment)

يمتدّ المفهوم خطوة إضافية بنشر الإصدارات المؤهَّلة آليًا فور مرورها بالمراحل السابقة، من غير تدخل بشري. مع ذلك تُفضِّل فرق كثيرة‑خاصةً في القطاعات المقيّدة تنظيميًا‑التمهّل عند مرحلة التسليم المستمر لاتخاذ قرار يدوي.

2. نظرة عامة على CircleCI وCoveralls

يُبرز الجدول تَكاملية الخدمتين: تُنفِّذ CircleCI سلسلة البناء والاختبار، ثم تُرسل أداة Coveralls‑ضمن خطوة في خط الأنابيب‑ملف تغطية الاختبارات لتحديث لوحة البيانات وعرض الانزياحات بين الإصدارات.

3. التحضير الأولي للمستودع

1. إنشاء المستودع في GitHub أو GitLab وإضافة ملف README وLICENSE.

2. تهيئة نظام التحكم في الإصدارات باستخدام استراتيجيات فروع واضحة (Git Flow، GitHub Flow).

3. كتابة اختبارات وحدات شاملة باستخدام إطار مناسب (Jest، Pytest، JUnit…) مع تفعيل ناتج التغطية (مثل lcov.info).

4. إضافة ملف .gitignore لمنع تتبع الملفات المؤقتة/البنائية.

5. إنشاء ملف coveralls.yml (اختياري) لتعريف خيارات مخصصة مثل معالجة الفروع أو المسارات المحذوفة.

4. ربط المستودع مع CircleCI

1. تسجيل الدخول إلى CircleCI عبر OAuth لمنصة الاستضافة.

2. منح CircleCI صلاحية القراءة والكتابة للمستودع المطلوب.

3. عند أول دخول تُنشئ CircleCI فرعًا تجريبيًا يحوي نموذج config.yml لتجربة التشغيل؛ يمكن حذفه لاحقًا.

5. بناء ملف التهيئة .circleci/config.yml

يُكتب الملف وفق مواصفة CircleCI 2.1 أو 2.1+ لأنه يتيح المعالِجات executors القابلة لإعادة الاستخدام. المثال التالي مشروع Node.js يُنشر إلى Docker Hub:

yaml
CopyEdit
version: 2.1

executors:
  node-docker:
    docker:
      - image: cimg/node:20.5
    environment:
      NODE_ENV: test

jobs:
  test:
    executor: node-docker
    steps:
      - checkout
      - restore_cache:
          keys:
            - v1-deps-{{ checksum "package-lock.json" }}
      - run: npm ci
      - save_cache:
          key: v1-deps-{{ checksum "package-lock.json" }}
          paths:
            - ~/.npm
      - run: npm run test:ci          # يولد lcov
      - run:
          name: Send coverage to Coveralls
          command: |
            npm install --global coveralls
            cat ./coverage/lcov.info | coveralls --verbose --repo-token $COVERALLS_REPO_TOKEN

  build_image:
    docker:
      - image: cimg/base:stable
    steps:
      - setup_remote_docker
      - checkout
      - run: |
          docker build -t myorg/myapp:$CIRCLE_SHA1 .
          echo $DOCKERHUB_TOKEN | docker login -u myorg --password-stdin
          docker push myorg/myapp:$CIRCLE_SHA1

workflows:
  ci_cd:
    jobs:
      - test
      - build_image:
          requires:
            - test

الشرح

• executor node-docker يحدد صورة رسمية مستقرة تدعم Node 20، ما يضمن اتساق البيئة محليًا وسحابيًا.

• استعادة التبعيات من ذاكرة التخزين يقلل زمن البناء خصوصًا مع مشروعات كبيرة.

• بعد تنفيذ npm run test:ci يتم توليد lcov.info ثم يُرسل عبر الأمر coveralls.

• يُخزن COVERALLS_REPO_TOKEN‑المحصول عليه من لوحة Coveralls‑كمتغيّر بيئي سري في إعدادات المشروع داخل CircleCI.

• setup_remote_docker يطلق محرك Docker مخصصًا يسمح ببناء صور داخل الحاوية.

• يعتمد build_image على نجاح test؛ أي فشل اختباري يمنع دفع الصور إلى السجل.

6. تفعيل Coveralls وخياراته المتقدمة

1. تسجيل المشروع في Coveralls.io واختيار منصة الاستضافة المناسبة.

2. نسخ الرمز المميز الخاص بالمستودع Repository Token وإضافته إلى متغيرات البيئة في CircleCI.

3. ضبط إعدادات تحقق حالة الدمج بحيث تُعَدّ عملية Pull Request فاشلة إذا انخفضت نسبة التغطية عن عتبة يحددها الفريق (مثل %-80).

4. استخدام خاصية Parallel Builds في Coveralls لإجمال تغطية الاختبارات التي تُشغَّل عبر مصفوفة منصات متوازية (Matrix) في CircleCI.

7. إدارة الأسرار والشهادات

• متغيرات البيئة السرية‑سواء رموز Coveralls أو بيانات اعتماد Docker Hub‑لا تُضع داخل المستودع بل في إعدادات المشروع.

• يمكن ربط CircleCI بـ Vault أو AWS Secrets Manager لتدوير الأسرار دوريًا وتدقيق الوصول.

• يُنصح باستخدام حساب خدمة خاص بدلاً من بيانات المستخدم الشخصية لتجنّب الخروقات عند مغادرة أحد أعضاء الفريق.

8. تصميم مرحلة النشر المستمر (CD)

يختلف مخطط النشر بحسب بنية المشروع:

يمكن تفعيل قواعد نشر مشروطة Conditional Rules استنادًا إلى الفرع (main أو release/*) أو وسم Git (v*). يوفر هذا تحكمًا دقيقًا يمنع نشر الميزات غير المستقرة.

9. مراقبة الأداء والتحسين

9‑1 تقليل زمن البناء

• التخزين المؤقت الطبقي Docker layer caching يقلّص زمن بناء الصور.

• استخدام orbs (قوالب CircleCI جاهزة) لتقليل ازدواجية التعليمات.

• توزيع الاختبارات عبر parallelism: N وتشغيلها على عقد متعددة.

9‑2 خفض التكاليف

• تفعيل Auto-cancel redundant builds لوقف خطوط الأنابيب القديمة عند دفع التزام جديد.

• تحديد resource_class أقل (مثل medium) للمهام غير كثيفة الحساب.

• مراقبة استهلاك الدقائق عبر لوحة CircleCI Insights.

10. الأمن والامتثال

• عزل بيانات الاعتماد في context مشفر مشترك بين مشروعات متعددة.

• مراجعة صلاحيات OAuth الممنوحة لـ CircleCI بصفة دورية.

• تفعيل SSH Permissionless checkout لتجنّب تخزين مفاتيح على الحاوية.

• الامتثال لمتطلبات GDPR أو HIPAA عند التعامل مع بيانات حساسة من خلال إضافة طبقات تشفير ومسارات تدقيق.

11. استكشاف الأخطاء الشائعة

12. الخلاصة

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

المراجع

1. CircleCI Documentation.

2. Coveralls Docs & API Reference.