تعلّم كيف تبني خطوط CI/CD فعّالة لمشاريعك الفردية باستخدام GitHub Actions وGitLab CI بأقل جهد، مع تجنب الفخاخ الشائعة التي تبطئ فرق العمل الكبيرة.
في آخر مشروع شخصي عملت عليه، كنت أقضي ساعتين يومياً في عمليات النشر اليدوي: بناء الكود، تشغيل الاختبارات، ضغط الملفات، ثم رفعها للسيرفر. بعد أسبوعين، اكتشفت أنني فقدت 28 ساعة من وقتي الثمين في مهام يمكن أتمتتها بالكامل. المشكلة ليست في الوقت المهدور فقط، بل في الأخطاء البشرية التي تتسلل عند التكرار: نسيت تشغيل اختبارات الوحدة مرة، ونسيت تحديث ملف التكوين في أخرى. هنا يأتي دور CI/CD ليس كتقنية فاخرة، بل كأداة بقاء للمطور الفردي الذي يريد التركيز على كتابة الكود بدلاً من إدارة النشر.
العديد من المطورين يعتقدون أن CI/CD مخصص للفرق الكبيرة فقط، أو أن إعداده يتطلب خبرة في DevOps. الحقيقة هي أن الأدوات الحديثة مثل GitHub Actions وGitLab CI جعلت العملية في متناول الجميع، بل وأصبحت ضرورية حتى للمشاريع الفردية. في هذا الدليل، سأريك كيف تبني خط إنتاج برمجي كامل من الصفر، خطوة بخطوة، بدون تعقيدات لا داعي لها، مع شرح ما يحدث خلف الكواليس في كل مرحلة.
CI اختصار لـ Continuous Integration، وهو عملية تلقائية لبناء واختبار الكود عند كل تغيير. عندما تدفع تغييراً جديداً لمستودع Git، يقوم CI بتشغيل سلسلة من الخطوات: تنزيل الاعتماديات، بناء المشروع، تشغيل الاختبارات، وإرسال تقرير بنتائج العملية. الهدف ليس فقط اكتشاف الأخطاء مبكراً، بل أيضاً ضمان أن الكود دائماً في حالة قابلة للبناء والنشر. خلف الكواليس، CI يعمل كآلة افتراضية (VM) أو حاوية (Container) تُنشأ من الصفر لكل عملية، مما يضمن بيئة نظيفة ومعزولة.
CD اختصار لـ Continuous Deployment أو Continuous Delivery، وهو امتداد لـ CI يضيف خطوة النشر التلقائي. الفرق بين Deployment وDelivery دقيق لكنه مهم: Delivery يعني أن الكود جاهز للنشر ولكنه يتطلب موافقة يدوية، بينما Deployment يعني النشر التلقائي الكامل. في المشاريع الفردية، Deployment هو الخيار الأكثر شيوعاً لأنه يقلل من التدخل اليدوي. عندما تنجح عملية CI، يقوم CD بنشر الكود تلقائياً إلى بيئة الإنتاج أو بيئة الاختبار، اعتماداً على التكوين. المشكلة التي يواجهها الكثيرون هنا هي عدم فهم الـ Event Loop الخاص بعملية النشر: هل يجب الانتظار حتى تكتمل جميع الاختبارات؟ ماذا يحدث إذا فشلت خطوة معينة؟
في عام 2023، أجرت Stack Overflow استبياناً أظهر أن 60% من المطورين يستخدمون GitHub Actions، بينما يستخدم 25% GitLab CI. الفرق الرئيسي بينهما ليس في الميزات بقدر ما هو في التكامل والبيئة. GitHub Actions يأتي مدمجاً مع GitHub، مما يجعله الخيار الطبيعي لمن يستخدم المنصة بالفعل. يوفر واجهة سهلة لإعداد الـ Workflows باستخدام ملفات YAML، ويدعم مجموعة واسعة من الـ Actions الجاهزة في السوق. من تجربتي، GitHub Actions ممتاز للمشاريع الصغيرة والمتوسطة، خاصة إذا كنت تستخدم خدمات أخرى من GitHub مثل Issues وProjects.
GitLab CI، من ناحية أخرى، يأتي كجزء من نظام GitLab المتكامل الذي يشمل أيضاً إدارة المشاريع، المراجعات البرمجية، والحاويات. الميزة الأكبر لـ GitLab CI هي الـ Auto DevOps، وهي ميزة تقوم تلقائياً بإعداد خطوط CI/CD بناءً على نوع المشروع. إذا كنت تعمل على مشروع يستخدم Docker أو Kubernetes، فإن GitLab CI يوفر تكاملاً أفضل مع هذه التقنيات. المشكلة التي واجهتها مع GitLab CI هي أن الوثائق أحياناً تكون معقدة ومبعثرة، خاصة للمبتدئين. أيضاً، الـ Runners (الآلات التي تشغل العمليات) في GitLab CI قد تكون أبطأ قليلاً من GitHub Actions، خاصة في المشاريع المجانية.
لنبدأ بإنشاء ملف workflow بسيط لمشروع Node.js. أولاً، انتقل إلى مستودع GitHub الخاص بك، وأنشئ مجلداً جديداً باسم `.github/workflows`. داخل هذا المجلد، أنشئ ملفاً باسم `ci.yml`. هذا الملف سيحتوي على جميع خطوات الـ Workflow. إليك مثال عملي:
name: Node.js CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [14.x, 16.x, 18.x]
steps:
- uses: actions/checkout@v3
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm run build --if-present
- run: npm test
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v3