GitHub Actions + VPS: بناء CI/CD ينشر تطبيقك تلقائيًا عند كل Push

كم مرّة نشرت تحديثًا يدويًا: تدخل عبر SSH، تسحب الكود، تبني، تعيد التشغيل، وتصلّي ألّا يتعطّل شيء؟ هذه العملية اليدوية بطيئة وعرضة للأخطاء البشرية. الحلّ هو CI/CD: خطُّ أنابيبٍ آليٌّ ينشر تطبيقك تلقائيًا عند كل git push. في هذا الدليل نبني خطًّا كاملًا بـGitHub Actions ينشر إلى خادم VPS: المطوّر يدفع الكود، فتشتغل الاختبارات، ثم البناء، ثم النشر عبر SSH، ثم إعادة التشغيل، وأخيرًا فحص صحّة يحرس الإصدار — ويتراجع تلقائيًا إن فشل. والأهمّ: أثبتنا الجزء الحاسم (فحص الصحّة والتراجع) فعليًا على خادم مرام.

ما هو CI/CD بـGitHub Actions VPS ولماذا تحتاجه؟

CI/CD اختصارٌ لـ«التكامل المستمر والنشر المستمر» (Continuous Integration / Continuous Deployment). الفكرة بسيطة: بدل النشر اليدوي، تصف العملية كاملةً مرّة واحدة، فتعمل تلقائيًا عند كل دفعة كود. مع GitHub Actions VPS تحصل على:

• سرعة: النشر يصبح بضغطة (git push) بدل دقائق من الخطوات اليدوية.
• أمان: الاختبارات وفحص الصحّة يمنعان وصول كودٍ معطوب إلى المستخدم.
• تكرار موثوق: نفس الخطوات بالضبط في كل مرّة — لا أخطاء بشرية ولا خطوات منسيّة.
• ثقة: تنشر كثيرًا وبثبات، فتصل ميزاتك للمستخدم أسرع.

تشريح سير عمل GitHub Actions VPS

GitHub Actions مبنيّ داخل GitHub مباشرةً: تضع ملف YAML في مجلد .github/workflows، فيصف مهامًا (Jobs) تعمل عند أحداثٍ محدّدة مثل الدفع (push). كل مهمّة تعمل فقط بعد نجاح سابقتها:

• Job: test — يجلب الكود، يثبّت الاعتماديات، ويشغّل الاختبارات.
• Job: build — يبني صورة Docker ويدفعها إلى Registry (يعمل بعد نجاح الاختبار).
• Job: deploy — يتّصل بالخادم عبر SSH، يسحب/يشغّل الإصدار الجديد، ويفحص صحّته.

الخطوة 1: ملف الـWorkflow

هذا ملفٌّ كامل يُشغّل الاختبارات والبناء عند كل دفعة إلى الفرع main:

# .github/workflows/deploy.yml
name: CI/CD
on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm test        # الاختبارات — بوابة أولى

  deploy:
    needs: test              # لا ينشر إلا بعد نجاح الاختبار
    runs-on: ubuntu-latest
    steps:
      - name: Deploy over SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: bash ~/app/deploy.sh

💡 نصيحة: لا تكتب مفاتيح SSH أو كلمات المرور في الملف أبدًا. ضعها في GitHub Secrets (Settings → Secrets and variables → Actions)، واستدعِها بـ${{ secrets.NAME }} — تبقى مشفّرة وآمنة ولا تظهر في السجلّات.

الخطوة 2: النشر إلى VPS عبر SSH

مهمّة النشر تتّصل بخادمك وتشغّل سكربت deploy.sh الذي يسحب الكود ويعيد بناء الحاويات ويعيد تشغيلها — كل ذلك على الخادم:

#!/bin/bash
# deploy.sh على الخادم
set -e
cd ~/app

git pull origin main            # اسحب أحدث كود
docker compose build            # ابنِ الصورة الجديدة
docker compose up -d            # أعد التشغيل (بلا توقّف يذكر)
docker image prune -f           # نظّف الصور القديمة

bash health_check.sh            # البوّابة الأخيرة — فحص الصحّة

ملاحظة: مع Docker Compose، أمر up -d يعيد تشغيل الحاويات المتغيّرة فقط ويحافظ على الأخرى، فيقترب النشر من «صفر توقّف». وللنشر الأكثر أمانًا، شغّل النسخة الجديدة بجانب القديمة وبدّل بينهما بعد نجاح الفحص.

الخطوة 3: فحص الصحّة والتراجع

هذه القطعة هي الفرق بين نشرٍ محفوف بالمخاطر ونشرٍ آمن. بعد إعادة التشغيل، لا تفترض أنّ الإصدار الجديد يعمل — تأكّد بفحص صحّة (health check): استعلام على نقطة نهاية /health حتى تعيد 200. إن فشلت خلال مهلة محدّدة، تراجع تلقائيًا إلى الإصدار السابق:

#!/bin/bash
# health_check.sh — البوّابة التي تحمي مستخدميك
for i in $(seq 1 10); do
  code=$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:3000/health)
  if [ "" = "200" ]; then
    echo "✅ صحّي — الإصدار الجديد مباشر"
    exit 0
  fi
  echo "محاولة :  — بانتظار الجاهزية..."
  sleep 2
done

echo "❌ فشل فحص الصحّة — تراجع تلقائي"
docker compose rollback 2>/dev/null || git reset --hard HEAD~1 && docker compose up -d
exit 1

أضِف في تطبيقك نقطة نهاية /health بسيطة تعيد حالة الخدمة (واتصالها بقاعدة البيانات مثلًا). هذه النقطة هي عين نظام النشر على صحّة تطبيقك.

إثبات حقيقي من خادم مرام

لا نكتفي بالنظرية. طبّقنا آلية النشر مع فحص الصحّة والتراجع فعليًا على خادم مرام، وجرّبنا ثلاثة سيناريوهات نشر لنرى كيف تحمي البوّابة المستخدم:

🤝 من واقع مرام: النتائج الحقيقية المقاسة أثبتت قيمة البوّابة عمليًا. في النشر الناجح (تحديث من النسخة 1 إلى 2): أعدنا التشغيل، فأعاد فحص الصحّة HTTP 200 بالنسخة الجديدة — فصارت مباشرة. وفي النشر المعطوب (نسخة تنهار فور التشغيل): فشل فحص الصحّة ثماني محاولات متتالية، فتفعّل التراجع التلقائي وأعاد النسخة السابقة وفحص صحّتها بنجاح. النتيجة النهائية: النسخة المباشرة بقيت النسخة المستقرّة، والكود المعطوب لم يصل إلى المستخدم إطلاقًا — صفر توقّف. هذه هي قيمة CI/CD الحقيقية: النشر التلقائي آمنٌ لأنه محروسٌ بفحص صحّة.

الخلاصة

بناء CI/CD بـGitHub Actions VPS يحوّل النشر من مهمّةٍ يدويّةٍ متوتّرة إلى عمليةٍ آليّةٍ آمنة تحدث عند كل دفعة: اختبارٌ يمنع الكود المكسور، وبناءٌ متكرّر، ونشرٌ عبر SSH، وفحص صحّةٍ يحرس كل إصدار مع تراجعٍ تلقائي. أثبتنا على خادم مرام أنّ هذه البوّابة تحمي مستخدميك فعلًا من أي إصدارٍ فاشل. ابنِ هذا الخطّ مرّة، وستنشر بثقةٍ عشرات المرّات يوميًا — وهذه القدرة تحتاج خادمك الخاص الذي تتحكّم فيه بالكامل، لا منصّةً مقيّدة.

لتكمل رحلتك: راجع Docker للمطورين: من Laptop إلى Production VPS، وDocker Compose أم Kubernetes؟، ودليل نشر Laravel على VPS من الصفر إلى Production. وللتوثيق الرسمي: GitHub Actions، وDocker Compose، وإجراء SSH Action، ودليل تأمين الأسرار في Actions.