إصداراتنا كانت كابوساً: كيف أنقذتني خطوط أنابيب CI/CD من جحيم النشر اليدوي؟

يا جماعة الخير، خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة كل ما أتذكرها بحكي “الحمد لله على نعمة الأتمتة”. كنا في ليلة خميس، الساعة تقترب من منتصف الليل، والفريق كله على أعصابه. كان عنا تحديث كبير لازم يطلع للعميل قبل نهاية الأسبوع.

أنا، بصفتي قائد الفريق وقتها، كنت المسؤول عن عملية النشر. الإجراءات كانت يدوية بحتة: سحب آخر نسخة من الكود من Git، تشغيل أوامر البناء (build) على جهازي المحلي، وبعدين رفع الملفات الناتجة يدوياً باستخدام بروتوكول FTP على السيرفر. بعد ما رفعت كل شي، وعملت إعادة تشغيل للسيرفر، فتحت الموقع… وإذا به شاشة بيضاء! “Error 500”.

ساعتها قلبي وقع في رجلي. شو القصة؟ “يا شباب، شغالة عندي على الجهاز!”، هاي كانت جملتي الشهيرة اللي ما بتفيد حدا. بدأنا عملية بحث محمومة عن السبب. مكالمات من العميل، توتر في الفريق، وساعات طويلة من التدقيق في كل ملف وكل سطر. بعد حوالي ثلاث ساعات من الجحيم، اكتشفنا المصيبة: نسيت أرفع ملف إعدادات صغير (config file) تم تحديثه. ملف واحد! كان كفيل بتعطيل كل شيء وتدمير ليلتنا.

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

ما هو الجحيم اليدوي الذي كنا نعيشه؟

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

• التنسيق البشري: “يا فلان، خلصت شغلك؟”، “مين اللي عمل merge آخر واحد؟”، “هل الكل متأكد إنه الكود تبعه ما بيكسر إشي؟”.
• البناء المحلي (Local Build): كل مطور يقوم ببناء المشروع على جهازه. وهذا يفتح باباً لمشاكل لا حصر لها بسبب اختلاف نسخ المكتبات، أنظمة التشغيل، والإعدادات. الجملة الشهيرة “It works on my machine!” هي نتاج هذه المرحلة.
• النقل اليدوي للملفات: استخدام برامج مثل FileZilla أو أوامر مثل scp لنقل الملفات واحداً تلو الآخر. وهنا تكمن احتمالية نسيان ملف، أو نقل ملف خاطئ، أو وضعه في المسار غير الصحيح.
• التعديلات اليدوية على السيرفر: أحياناً نحتاج لتشغيل أوامر على السيرفر بعد النشر، مثل تحديث قاعدة البيانات أو مسح الكاش. هذه أيضاً تتم يدوياً، مما يزيد من احتمالية الخطأ.
• غياب الاختبارات الآلية: لم يكن لدينا وقت أو آلية لتشغيل مجموعة شاملة من الاختبارات قبل النشر. كنا نعتمد على الاختبار اليدوي السريع بعد النشر، وهذا يعني أن المستخدمين هم أول من يكتشف الأخطاء أحياناً.

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

المنقذ: خطوط أنابيب CI/CD (Pipelines)

هنا يأتي دور الأبطال: التكامل المستمر (CI) والتسليم/النشر المستمر (CD). هذه ليست مجرد مصطلحات تقنية رنانة، بل هي فلسفة ومنهجية عمل تغير قواعد اللعبة.

ما هو التكامل المستمر (Continuous Integration – CI)؟

ببساطة، هو ممارسة دمج التغييرات البرمجية من جميع المطورين في مستودع مركزي (مثل Git) بشكل متكرر. مع كل عملية دمج، يتم تشغيل عملية “بناء” و “اختبار” آلية. الهدف؟ اكتشاف مشاكل التكامل والأخطاء في وقت مبكر جداً، قبل أن تتراكم وتصبح كارثة.

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

ما هو التسليم/النشر المستمر (Continuous Delivery/Deployment – CD)؟

هذا هو الجزء الذي يكمل الـ CI. بعد أن ينجح الكود في مرحلة التكامل (البناء والاختبار)، تأتي مرحلة الـ CD.

• التسليم المستمر (Continuous Delivery): يعني أن كل تغيير يمر بنجاح من مرحلة الـ CI يتم تجهيزه تلقائياً ليكون جاهزاً للنشر. يتم إنشاء “قطعة أثرية” (artifact) – مثل صورة Docker أو ملف مضغوط – وتخزينها. عملية النشر إلى بيئة الإنتاج الفعلية قد تتطلب ضغطة زر يدوية، مما يعطي تحكماً إضافياً لفريق العمل.
• النشر المستمر (Continuous Deployment): هي الخطوة الأكثر تقدماً. هنا، كل تغيير ينجح في جميع المراحل السابقة يتم نشره تلقائياً إلى بيئة الإنتاج بدون أي تدخل بشري. هذا يتطلب ثقة عالية جداً في عملية الاختبار الآلي.

هذه المراحل مجتمعة تشكل ما نسميه “خط الأنابيب” أو الـ Pipeline. تماماً مثل خط تجميع السيارات، الكود يدخل من جهة كمادة خام، ويمر عبر محطات آلية (بناء، اختبار، فحص…)، ليخرج من الجهة الأخرى كمنتج نهائي جاهز للمستخدم.

لنطبق عملياً: بناء أول Pipeline باستخدام GitHub Actions

الكلام النظري جميل، لكن “ورجيني الشغل”. دعونا نبني مثالاً بسيطاً وواقعياً لـ Pipeline يقوم بنشر تطبيق ويب (مبني بـ Node.js مثلاً) على سيرفر Linux باستخدام GitHub Actions، وهي أداة CI/CD مدمجة مباشرة في GitHub.

لنفترض أن لدينا مشروع React أو Vue بسيط. خطوات النشر اليدوية كانت: npm run build ثم scp -r build/* user@server:/var/www/html.

سنقوم بأتمتة هذا بالكامل.

الخطوة 1: إنشاء ملف الـ Workflow

في جذر مشروعك، أنشئ مجلداً باسم .github وبداخله مجلد آخر باسم workflows. داخل هذا المجلد، أنشئ ملفاً جديداً باسم deploy.yml.

# .github/workflows/deploy.yml

name: Deploy to Production

# متى يتم تشغيل هذا الـ Pipeline؟
# هنا، سيتم تشغيله عند كل عملية push إلى الفرع الرئيسي (main)
on:
  push:
    branches: [ "main" ]

jobs:
  # يمكن أن يكون لدينا عدة وظائف، هنا لدينا وظيفة واحدة اسمها deploy
  deploy:
    # على أي نوع من الأجهزة سيتم تشغيل هذه الوظيفة؟
    runs-on: ubuntu-latest

    # الخطوات التي سيتم تنفيذها بالترتيب
    steps:
      # الخطوة الأولى: سحب الكود من المستودع
      - name: Checkout code
        uses: actions/checkout@v3

      # الخطوة الثانية: إعداد بيئة Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          # استخدام الكاش لتسريع عملية تحميل الاعتماديات في المرات القادمة
          cache: 'npm'

      # الخطوة الثالثة: تثبيت الاعتماديات
      # استخدام npm ci بدلاً من npm install لأنه أسرع وأكثر أماناً في بيئات CI
      - name: Install dependencies
        run: npm ci

      # الخطوة الرابعة: تشغيل الاختبارات (مرحلة CI)
      # إذا فشلت هذه الخطوة، سيتوقف الـ Pipeline بالكامل
      - name: Run tests
        run: npm test

      # الخطوة الخامسة: بناء المشروع للإنتاج (مرحلة CD)
      - name: Build application
        run: npm run build

      # الخطوة السادسة: النشر على السيرفر (مرحلة CD)
      - name: Deploy to server
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT }}
          source: "build/*" # الملفات التي سيتم نسخها
          target: "/var/www/html" # المسار على السيرفر

الخطوة 2: إعداد الأسرار (Secrets)

لاحظ في الخطوة الأخيرة أننا استخدمنا ${{ secrets.SSH_HOST }}. هذا هو الجزء الأهم للحفاظ على أمان معلوماتك. إياك ثم إياك أن تكتب كلمات المرور أو مفاتيح SSH مباشرة في الملف!

بدلاً من ذلك، نستخدم GitHub Secrets:

1. اذهب إلى مستودعك على GitHub.
2. انقر على “Settings” > “Secrets and variables” > “Actions”.
3. انقر على “New repository secret” وأضف الأسرار التالية:
   • SSH_HOST: عنوان IP أو اسم النطاق الخاص بسيرفرك.
   • SSH_USERNAME: اسم المستخدم الذي تستخدمه للاتصال بالسيرفر.
   • SSH_PRIVATE_KEY: مفتاح SSH الخاص بك الذي يسمح بالاتصال بدون كلمة مرور.
   • SSH_PORT: منفذ SSH (عادة 22).

النتيجة؟ سحر خالص! ✨

الآن، في كل مرة يقوم أي مطور في الفريق بعمل git push للفرع main، سيحدث التالي تلقائياً:

1. يبدأ GitHub Action بالعمل.
2. يسحب آخر نسخة من الكود.
3. يثبت الاعتماديات.
4. يشغل جميع الاختبارات الآلية.
5. إذا نجحت الاختبارات، يقوم ببناء نسخة الإنتاج من التطبيق.
6. يقوم بنسخ الملفات المبنية بأمان إلى السيرفر.

كل هذا يحدث في دقائق، بدون أي تدخل بشري، وبشكل موثوق 100%. إذا فشلت أي خطوة (مثلاً، فشل أحد الاختبارات)، يتوقف الـ Pipeline ويرسل إشعاراً للفريق، ولا يتم نشر الكود المعطوب أبداً.

نصيحة من أبو عمر

لا تكتفِ بالنشر على الإنتاج مباشرة. أفضل ممارسة هي إنشاء فرع آخر اسمه develop أو staging. قم بضبط الـ Pipeline لينشر التغييرات من هذا الفرع إلى سيرفر “تجريبي” (Staging Server) يشبه بيئة الإنتاج تماماً. هذا يسمح لك وللعميل بمراجعة التغييرات قبل دمجها في الفرع main ونشرها للمستخدمين الفعليين.

الخلاصة: استثمر في راحة بالك

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

• ✅ تقليل الأخطاء البشرية: الآلة لا تنسى ملفات ولا تخطئ في كتابة الأوامر.
• 🚀 سرعة في النشر: ما كان يأخذ ساعة من العمل اليدوي والتوتر، أصبح الآن يتم في دقائق.
• 🛡️ زيادة الموثوقية: الاختبارات الآلية تضمن جودة الكود قبل وصوله للإنتاج.
• 😌 راحة البال: لم نعد نخاف من عمليات النشر. أصبحنا ننشر التحديثات عدة مرات في اليوم بثقة تامة.
• 🧑‍💻 تركيز المطورين: أصبح الفريق يركز على كتابة الكود وحل المشاكل، بدلاً من إضاعة الوقت في عمليات النشر المعقدة.

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