أساسيات CI/CD

قبل أن تكتب سطر YAML واحد أو تنشئ Workflow في GitHub Actions، يجب أن تفهم مفهوم CI/CD لأنه هو السبب الحقيقي لوجود GitHub Actions وJenkins وGitLab CI وAzure DevOps وغيرها.

في الشركات الكبيرة لا يتم النظر إلى GitHub Actions على أنه مجرد أداة تشغيل أوامر، بل كجزء من منظومة أكبر اسمها:

Software Delivery Lifecycle

أي دورة حياة تسليم البرمجيات من لحظة كتابة الكود حتى وصوله للمستخدم.

كيف كانت الأمور قبل CI/CD؟

لنفترض أن لديك فريق مكون من:

5 مطورين Backend
3 مطورين Frontend
2 QA Testers

كل مطور يعمل على جهازه.

السيناريو التقليدي

المطور الأول يكتب:

function calculatePrice()
{
    return 100;
}

المطور الثاني يكتب:

function calculatePrice()
{
    return 150;
}

المطور الثالث يغير نفس الملف.

في نهاية الأسبوع:

الجميع يرفع الكود.

ثم تبدأ الكوارث:

مشاكل الدمج

Merge Conflicts

اختبارات فاشلة

Application Errors

أخطاء Production

500 Internal Server Error

توقف الخدمة

Downtime

كانت الشركات تعاني من:

بطء النشر
كثرة الأخطاء
فقدان الاستقرار
ضغط كبير على الفرق

ومن هنا ظهر مفهوم:

Continuous Integration (CI)

ما هو Continuous Integration؟

CI يعني:

دمج التعديلات البرمجية باستمرار مع التحقق منها تلقائياً.

المعنى البسيط

كل مرة يرفع مطور كوداً:

git push

يتم مباشرة:

بناء المشروع
تشغيل الاختبارات
تحليل الكود
التحقق من الجودة

إذا نجحت:

✅ يقبل التعديل

إذا فشلت:

❌ يتم اكتشاف الخطأ فوراً

لماذا نحتاج CI؟

تخيل أنك تعمل على Laravel.

لديك:

public function index()
{
    return User::all();
}

أحد المطورين عدل الكود إلى:

public function index()
{
    return User::everything();
}

لكن:

everything()

غير موجودة.

بدون CI:

يدخل الخطأ إلى Main Branch.

يكتشف بعد أيام.

مع CI:

عند Push:

php artisan test

يفشل مباشرة.

الخطأ يُكتشف خلال دقائق بدلاً من أيام.

كيف يعمل CI؟

الخطوات عادة:

Developer
    ↓
Git Push
    ↓
GitHub Actions
    ↓
Install Dependencies
    ↓
Run Tests
    ↓
Code Analysis
    ↓
Result

مثال Laravel CI

عند Push:

Push
 ↓
Composer Install
 ↓
PHPUnit
 ↓
PHPStan
 ↓
Pint
 ↓
Success

Composer Install

تنزيل الحزم:

composer install

PHPUnit

اختبار التطبيق:

php artisan test

PHPStan

تحليل الكود:

vendor/bin/phpstan analyse

Pint

فحص تنسيق الكود:

./vendor/bin/pint

إذا نجحت جميع المراحل:

✅ Build Passed

إذا فشلت مرحلة واحدة:

❌ Build Failed

فوائد CI

1. اكتشاف الأخطاء مبكراً

بدلاً من:

بعد أسبوع

تصبح:

بعد دقيقة

2. دمج مستمر

الكود يبقى دائماً صالحاً للعمل.

3. تقليل مشاكل الدمج

Merge Conflicts أقل بكثير.

4. رفع جودة الكود

كل شيء يتم اختباره.

ما هو Continuous Delivery (CD)؟

بعد أن تأكدنا أن الكود صحيح عبر CI.

السؤال:

ماذا بعد؟

هنا يأتي:

Continuous Delivery

تعريف Continuous Delivery

هو جعل التطبيق دائماً جاهزاً للنشر.

لاحظ:

في Continuous Delivery لا يتم النشر تلقائياً.

بل يتم تجهيز كل شيء للنشر.

التسلسل

Push
 ↓
Tests
 ↓
Build
 ↓
Docker Image
 ↓
Ready For Deploy

الشركة تستطيع النشر في أي لحظة.

مثال عملي

بعد نجاح الاختبارات:

يبني GitHub Actions صورة Docker.

docker build -t app .

ثم يرفعها:

docker push ghcr.io/app

ثم تصبح الصورة جاهزة.

لكن لا يتم النشر تلقائياً.

يأتي مدير المشروع ويقول:

“انشر الإصدار.”

فيتم النشر بضغطة زر.

لماذا تستخدم الشركات Continuous Delivery؟

لأنها تريد:

التحكم بوقت النشر
مراجعة نهائية
موافقة الإدارة
اختبار إضافي

ما هو Continuous Deployment؟

هذا المستوى الأعلى.

تعريف Continuous Deployment

أي تغيير ينجح في الاختبارات يتم نشره مباشرة للإنتاج.

بدون أي تدخل بشري.

التسلسل

Push
 ↓
Tests
 ↓
Build
 ↓
Docker Image
 ↓
Deploy
 ↓
Production

بمجرد:

git push

بعد دقائق:

التحديث موجود على الموقع.

مثال حقيقي

لنفترض:

موقعك يعمل على Coolify.

عند Push:

Push
 ↓
GitHub Actions
 ↓
Run Tests
 ↓
Build Docker Image
 ↓
Push To Registry
 ↓
Trigger Coolify
 ↓
Deploy

بعد 3 دقائق:

الإصدار الجديد يعمل.

الفرق بين Continuous Delivery و Continuous Deployment

Continuous Delivery

Push
 ↓
Build
 ↓
Ready
 ↓
Human Approval
 ↓
Deploy

Continuous Deployment

Push
 ↓
Build
 ↓
Deploy Automatically

الفرق الوحيد تقريباً:

هل يوجد تدخل بشري أم لا.

متى نستخدم كل نوع؟

المشاريع الحساسة

مثل:

البنوك
الأنظمة الحكومية
المستشفيات

غالباً تستخدم:

Continuous Delivery

لأن النشر يحتاج موافقات.

المشاريع السريعة

مثل:

SaaS
Startup
تطبيقات ويب حديثة

غالباً تستخدم:

Continuous Deployment

دورة حياة الكود من المطور إلى الإنتاج

هذه أهم نقطة يجب فهمها.

المرحلة 1: كتابة الكود

المطور يعمل على جهازه.

Local Machine

مثال:

Route::get('/users');

المرحلة 2: Commit

حفظ التعديلات.

git commit

المرحلة 3: Push

رفع الكود.

git push

المرحلة 4: GitHub

الكود يصل إلى المستودع.

المرحلة 5: Trigger

يتم تشغيل Workflow.

Push Event

المرحلة 6: CI

تشغيل:

Composer
PHPUnit
PHPStan
Pint

المرحلة 7: Build

بناء التطبيق.

مثال:

docker build

المرحلة 8: Registry

رفع الصورة.

مثل:

Docker Hub
GitHub Container Registry
Amazon Elastic Container Registry

المرحلة 9: Deploy

نشر التطبيق.

على:

VPS
Docker
Kubernetes
Coolify

المرحلة 10: Production

المستخدم يرى التحديث.

الشكل الكامل

Developer
    ↓
Git Commit
    ↓
Git Push
    ↓
GitHub
    ↓
GitHub Actions
    ↓
Tests
    ↓
Build
    ↓
Registry
    ↓
Deploy
    ↓
Production

GitHub Actions داخل منظومة DevOps

الخطأ الشائع عند المبتدئين:

يعتقد أن GitHub Actions هو DevOps.

وهذا غير صحيح.

GitHub Actions مجرد جزء صغير من منظومة أكبر.

منظومة DevOps الكاملة

Developer
     ↓
GitHub
     ↓
GitHub Actions
     ↓
Docker
     ↓
Container Registry
     ↓
Coolify / Kubernetes
     ↓
Server
     ↓
Monitoring
     ↓
Logs

أين يقف GitHub Actions؟

في المنتصف تماماً.

هو المسؤول عن:

Automation

تشغيل المهام.

CI

الاختبارات.

CD

البناء والنشر.

Integration

ربط الأدوات ببعضها.

مثال قريب من بيئتك

بما أنك تعمل على:

Laravel
Docker
Coolify
VPS

فالمسار الاحترافي سيكون:

Laravel
   ↓
GitHub
   ↓
GitHub Actions
   ↓
Run Tests
   ↓
Build Docker Image
   ↓
Push To GHCR
   ↓
Notify Coolify
   ↓
Deploy New Version
   ↓
Production Server

هذه هي الصورة الذهنية التي يجب أن تبقى في رأسك دائماً:

CI = التأكد أن الكود صحيح

CD (Delivery) = تجهيز الكود للنشر

CD (Deployment) = نشر الكود تلقائياً

GitHub Actions = المحرك الذي ينفذ كل ذلك

وفي الدرس التالي عندما نبدأ بنية GitHub Actions (Workflow → Job → Step → Runner → Action) ستفهم لأول مرة كيف تتحول هذه المفاهيم النظرية إلى ملفات YAML حقيقية تعمل داخل GitHub.