CI/CD من الصفر: عندما يتحول الكود إلى كابوس بدون أن تشعر

تخيل أنك تعمل على مشروعك الجديد منذ ثلاثة أشهر، وكل شيء يسير على ما يرام. ثم يأتي يوم النشر. تضغط زر git push، تنتظر، ثم تكتشف أن التطبيق لا يعمل على السيرفر. تبدأ رحلة البحث عن الخطأ: هل نسيت ملفاً؟ هل المكتبة الجديدة غير متوافقة مع النسخة القديمة من Node.js؟ هل نسيت تحديث ملفات البيئة؟ بعد ساعتين من العذاب، تكتشف أنك نسيت تشغيل اختبارات الوحدة. النتيجة؟ موقعك معطل لمدة ساعة كاملة، والعملاء يرسلون رسائل غاضبة. هذه ليست قصة خيالية، بل هي واقع يومي لمئات المطورين الذين لم يتبنوا CI/CD بعد.

الحقيقة المؤلمة هي أن نشر الكود يدوياً ليس مجرد عملية بطيئة، بل هو قنبلة موقوتة. كل مرة تضغط فيها زر النشر، أنت تخاطر بكسر شيء ما دون أن تدري. وعندما يحدث الخطأ، ستضيع ساعات في البحث عن السبب بدلاً من التركيز على تطوير الميزات الجديدة. لكن هناك حلاً: CI/CD، أو التكامل المستمر والنشر المستمر. هذه ليست مجرد أدوات، بل هي ثقافة برمجية تنقذك من الكوارث قبل أن تقع.

ما هو CI/CD حقاً؟ ولماذا لا يكفي أن تقول "أنا أستخدم Git"

الكثير من المطورين يعتقدون أن استخدام Git يعني أنهم يمارسون CI/CD. هذا أبعد ما يكون عن الحقيقة. Git هو مجرد أداة لإدارة النسخ، لكنه لا يضمن أن الكود يعمل بشكل صحيح بعد كل تغيير. CI/CD هو عملية آلية تضمن أن كل تغيير في الكود يمر عبر اختبارات محددة قبل أن يصل إلى الإنتاج. الفرق بين الاثنين مثل الفرق بين قيادة سيارة يدوياً وقيادة سيارة ذات ناقل حركة أوتوماتيكي مع نظام ملاحة ذكي.

في CI (التكامل المستمر)، كل مرة تقوم فيها بعمل git push، يتم تشغيل سلسلة من العمليات: بناء الكود، تشغيل اختبارات الوحدة، فحص جودة الكود، وربما حتى اختبارات التكامل. إذا فشل أي خطوة، يتم إيقاف العملية وإعلامك فوراً. أما CD (النشر المستمر)، فهو الخطوة التالية: إذا مرت جميع الاختبارات بنجاح، يتم نشر الكود تلقائياً إلى بيئة الإنتاج أو بيئة التقييم. الفكرة ليست مجرد أتمتة النشر، بل هي ضمان أن الكود الذي يصل إلى الإنتاج هو كود موثوق به.

الخطوة الأولى: إعداد بيئة CI بسيطة باستخدام GitHub Actions

لنبدأ بشيء عملي. سنستخدم GitHub Actions لأنه يأتي مدمجاً مع GitHub ولا يتطلب إعدادات معقدة. الفكرة هنا هي أننا نريد أن نقول لـ GitHub: "كل مرة أدفع كوداً جديداً إلى الفرع الرئيسي، قم ببناء الكود وتشغيل الاختبارات. إذا فشل أي شيء، أرسل لي إشعاراً."

أولاً، تحتاج إلى ملف YAML في مجلد .github/workflows في مشروعك. هذا الملف سيحدد ما يجب فعله عند كل push. إليك مثال بسيط لمشروع Node.js:

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

هذا الملف يفعل عدة أشياء مهمة: أولاً، يحدد أنه يجب تشغيلWorkflow عند كل push أو pull request إلى الفرع main. ثم يحدد أنه سيتم تشغيل الوظيفة على أحدث نسخة من Ubuntu، وسيتم اختبار الكود على ثلاث نسخ مختلفة من Node.js. الخطوات تشمل: سحب الكود، إعداد Node.js، تثبيت الاعتماديات باستخدام npm ci (الذي أسرع وأكثر موثوقية من npm install)، بناء الكود، ثم تشغيل الاختبارات.

لاحظ استخدام matrix هنا. هذا يعني أن الكود سيتم اختباره على ثلاث نسخ مختلفة من Node.js، مما يضمن التوافق مع بيئات مختلفة. هذه ميزة قوية جداً في CI، لأنها تمنع المفاجآت عندما تنتقل من بيئة التطوير إلى بيئة الإنتاج.

ماذا يحدث خلف الكواليس في الذاكرة والمعالج؟

عندما تقوم بعمل push، يرسل GitHub إشعاراً إلى خادماته التي تبدأ في تخصيص بيئة افتراضية جديدة. هذه البيئة عبارة عن حاوية Docker خفيفة تعمل على آلة افتراضية. يتم تحميل الكود الخاص بك إلى هذه الحاوية، ثم يبدأ تنفيذ الخطوات المحددة في ملف YAML. كل خطوة هي عملية مستقلة، وإذا فشلت أي خطوة، يتم إيقاف العملية بأكملها وإعلامك.

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

من CI إلى CD: النشر التلقائي بدون خوف

الآن بعد أن أصبح لدينا CI يعمل، حان الوقت للانتقال إلى CD. الفكرة هنا هي أن الكود الذي يمر بجميع الاختبارات يتم نشره تلقائياً إلى بيئة الإنتاج. قد يبدو هذا مخيفاً، لكن مع الإعداد الصحيح، يصبح النشر التلقائي هو الخيار الأكثر أماناً.

لنأخذ مثالاً على نشر تطبيق Node.js إلى Heroku. سنعدل ملف GitHub Actions السابق ليشمل خطوة النشر:

name: Node.js CI/CD

on:
 push:
 branches: [ main ]

jobs:
 build:
 runs-on: ubuntu-latest
 
 steps:
 - uses: actions/checkout@v3
 - name: Use Node.js
 uses: actions/setup-node@v3
 with:
 node-version: 18.x
 - run: npm ci
 - run: npm run build --if-present
 - run: npm test
 
 deploy:
 needs: build
 runs-on: ubuntu-latest
 
 steps:
 - uses: actions/checkout@v3
 - name: Deploy to Heroku
 uses: akhileshns/heroku-deploy@v3.12.12
 with:
 heroku_api_key: ${{secrets.HEROKU_API_KEY}}
 heroku_app_name: "your-heroku-app-name"
 heroku_email: "your-email@example.com"

في هذا المثال، أضفنا وظيفة جديدة تسمى deploy تعتمد على نجاح وظيفة build. هذا يعني أن النشر لن يحدث إلا إذا مرت جميع الاختبارات بنجاح. لاحظ استخدام secrets.HEROKU_API_KEY. هذه هي الطريقة الآمنة لتخزين المفاتيح السرية في GitHub. لا يجب أبداً كتابة المفاتيح السرية مباشرة في ملف YAML، لأنها ستظهر في سجلات GitHub ويمكن لأي شخص الوصول إليها.

من تجربتي، أفضل طريقة لإدارة النشر هي استخدام بيئتين: staging و production. الكود ينتقل أولاً إلى staging، حيث يمكنك اختباره يدوياً قبل أن ينتقل إلى production. هذا يضيف طبقة إضافية من الأمان. يمكنك تحقيق ذلك باستخدام فروع مختلفة في Git، مثلاً فرع main للنشر إلى staging وفرع production للنشر إلى الإنتاج.

الفخاخ التي يقع فيها الجميع عند إعداد CD

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

فخ آخر هو عدم وجود آلية للرجوع السريع (Rollback). حتى مع أفضل إعدادات CI/CD، قد يحدث خطأ ما. يجب أن تكون قادراً على العودة إلى النسخة السابقة من التطبيق في ثوانٍ. معظم منصات النشر مثل Heroku و AWS توفر هذه الميزة، لكن يجب إعدادها مسبقاً. لا تنتظر حتى يحدث الخطأ لتكتشف أنك لا تملك خطة للرجوع.

• •عدم اختبار بيئة النشر نفسها (مثل اختلاف إصدارات قواعد البيانات)
• •عدم وجود آلية للرجوع السريع (Rollback)
• •نشر مفاتيح سرية في ملفات التكوين بدلاً من استخدام متغيرات البيئة
• •عدم مراقبة التطبيق بعد النشر (مثل استخدام أدوات مثل Sentry أو Datadog)
• •نشر جميع التغييرات دفعة واحدة بدلاً من استخدام ميزة Feature Flags

CI/CD للمشاريع الصغيرة: هل يستحق العناء؟

هناك اعتقاد خاطئ شائع أن CI/CD مخصص فقط للمشاريع الكبيرة أو الفرق الكبيرة. الحقيقة هي أن CI/CD أكثر أهمية للمشاريع الصغيرة والفردية. لماذا؟ لأنك عندما تعمل بمفردك، ليس لديك فريق لمراجعة الكود أو اختبار الميزات الجديدة. كل خطأ يعني أنك ستضيع وقتاً ثميناً في البحث عن المشكلة بدلاً من تطوير المنتج.

خذ مثلاً مشروعاً صغيراً تستخدمه شخصياً أو لعملائك. بدون CI/CD، كل مرة تريد فيها إضافة ميزة جديدة، ستضطر إلى اختبار كل شيء يدوياً، ثم نشر الكود يدوياً. هذا ليس فقط بطيء، بل هو عرضة للأخطاء. مع CI/CD، يمكنك التركيز على كتابة الكود، واثقاً أن أي خطأ سيتم اكتشافه فوراً قبل أن يصل إلى المستخدمين.

من تجربتي مع مشاريع صغيرة، وجدت أن إعداد CI/CD يستغرق أقل من ساعة، لكنه يوفر عشرات الساعات على المدى الطويل. على سبيل المثال، في أحد مشاريعي الجانبية، كنت أقضي حوالي ساعة أسبوعياً في اختبار الكود يدوياً قبل النشر. بعد إعداد CI/CD، اختفت هذه الساعة تماماً، وأصبحت واثقاً أن الكود الذي يصل إلى الإنتاج هو كود موثوق به.

كيف تبدأ بميزانية صفر؟

إذا كنت تعمل بمفردك أو بميزانية محدودة، لا داعي للقلق. هناك العديد من الأدوات المجانية التي يمكنك استخدامها. GitHub Actions يوفر 2000 دقيقة مجانية شهرياً، وهو أكثر من كافٍ للمشاريع الصغيرة. Heroku يوفر طبقة مجانية لتشغيل التطبيقات الصغيرة. حتى إذا كنت تستخدم خدمات مدفوعة مثل AWS أو DigitalOcean، يمكنك البدء بخطة صغيرة جداً ثم التوسع عند الحاجة.

السر هنا هو البدء ببساطة. لا تحاول إعداد نظام معقد من اليوم الأول. ابدأ بـ CI فقط، مع اختبارات الوحدة الأساسية. عندما تشعر بالراحة، أضف خطوة النشر التلقائي. ثم، عندما ينمو المشروع، يمكنك إضافة المزيد من الميزات مثل اختبارات الأداء ومراقبة التطبيق بعد النشر.

ما وراء الأساسيات: CI/CD المتقدم للمطور الفردي الطموح

الآن بعد أن أصبحت لديك أساسيات CI/CD، حان الوقت للتفكير في كيفية جعل النظام أكثر ذكاءً. مثلاً، بدلاً من تشغيل جميع الاختبارات عند كل push، يمكنك استخدام ما يسمى بـ "Smart Testing"، حيث يتم تشغيل الاختبارات المتعلقة فقط بالتغييرات التي قمت بها. هذا يوفر وقتاً كبيراً، خاصة في المشاريع الكبيرة.

هناك أيضاً مفهوم الـ "Canary Deployments"، حيث يتم نشر التغييرات الجديدة إلى مجموعة صغيرة من المستخدمين أولاً، ثم يتم مراقبة الأداء والأخطاء قبل نشرها للجميع. هذا يقلل من مخاطر النشر بشكل كبير. على سبيل المثال، شركة Netflix تستخدم هذه التقنية لتحديث خدماتها دون أن يشعر المستخدمون بأي انقطاع.

name: Canary Deployment

on:
 push:
 branches: [ main ]

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - run: npm ci
 - run: npm test

 deploy-canary:
 needs: build
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - name: Deploy to Canary
 run: |
 # هنا يمكنك استخدام أداة مثل Kubernetes أو AWS CodeDeploy
 # لنشر التغييرات إلى مجموعة صغيرة من المستخدمين
 echo "Deploying to Canary environment"
 # مثال باستخدام AWS CLI:
 # aws deploy create-deployment --application-name my-app --deployment-group-name canary --s3-location bucket=my-bucket,bundleType=zip,key=app.zip

في هذا المثال، أضفنا وظيفة deploy-canary التي تعتمد على نجاح وظيفة build. هذه الوظيفة ستقوم بنشر التغييرات إلى بيئة Canary أولاً. إذا سارت الأمور على ما يرام، يمكنك لاحقاً تشغيل وظيفة أخرى لنشر التغييرات إلى جميع المستخدمين.

مراقبة التطبيق بعد النشر: الخطوة التي يتجاهلها الجميع

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

على سبيل المثال، يمكنك إعداد Sentry لتتبع الأخطاء في تطبيقك وإرسال إشعارات فورية عند حدوث أي خطأ جديد. هذا يسمح لك بالتصرف بسرعة قبل أن يؤثر الخطأ على عدد كبير من المستخدمين. إليك مثال على كيفية إعداد Sentry في تطبيق Node.js:

const Sentry = require('@sentry/node');

Sentry.init({
 dsn: process.env.SENTRY_DSN,
 tracesSampleRate: 1.0,
 environment: process.env.NODE_ENV || 'development'
});

// في مكان ما في الكود، يمكنك التقاط الأخطاء
try {
 // الكود الذي قد يسبب خطأ
} catch (error) {
 Sentry.captureException(error);
 throw error;
}

مع هذا الإعداد، كل خطأ في التطبيق سيتم تسجيله وإرساله إلى لوحة تحكم Sentry، حيث يمكنك رؤيته وتحليله. يمكنك أيضاً إعداد إشعارات عبر البريد الإلكتروني أو Slack لتتلقى تنبيهاً فورياً عند حدوث أي خطأ جديد.

خلاصة المهندس: نصيحة واحدة تغير كل شيء

إذا كنت ستأخذ شيئاً واحداً فقط من هذا المقال، فليكن هذا: ابدأ اليوم. لا تنتظر حتى يصبح مشروعك كبيراً أو معقداً. ابدأ بمشروعك الصغير الحالي، وقم بإعداد CI/CD بسيط باستخدام GitHub Actions و Heroku أو أي خدمة أخرى. خصص ساعة واحدة اليوم لإعداد ملف YAML بسيط وتشغيل اختبارات الوحدة تلقائياً عند كل push. هذه الخطوة الصغيرة ستغير طريقة عملك للأبد، وستجعلك مطوراً أكثر كفاءة وثقة.

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