مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow)

مقدمة في GitHub Actions: لماذا أصبحت جزءاً أساسياً من هندسة النشر الحديثة؟

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

الفكرة الأساسية بسيطة: عند حدوث حدث معين مثل push أو pull_request، يتم تشغيل مسار عمل آلي ينفذ سلسلة خطوات محددة مسبقاً. هذا يختصر الأخطاء البشرية ويمنح الفريق رؤية فورية عن سلامة التغييرات قبل دمجها أو نشرها.

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

ما هو Workflow وما مكوناته الأساسية؟

مسار العمل أو Workflow هو ملف إعداد مكتوب بصيغة YAML يوضع داخل المسار .github/workflows/. هذا الملف يعرّف متى يبدأ التنفيذ، وعلى أي بيئة يعمل، وما الخطوات التي يجب تنفيذها.

العناصر الرئيسية داخل الملف

• name: اسم المسار كما يظهر في واجهة GitHub.
• on: الحدث الذي يطلق التنفيذ.
• jobs: مجموعة الوظائف المطلوب تشغيلها.
• runs-on: نوع الخادم المؤقت أو runner المستخدم أثناء التنفيذ.
• steps: الخطوات الفعلية مثل جلب الكود، تثبيت الاعتماديات، وتشغيل الاختبارات.

معمارياً، يمكن اعتبار كل job خادماً مؤقتاً مستقلاً. هذا يعني أن الملفات الناتجة من وظيفة لا تنتقل تلقائياً إلى وظيفة أخرى إلا إذا استخدمت آليات مثل artifacts أو التخزين المرحلي.

بنية المجلدات الصحيحة لكتابة أول Workflow

لكي يتعرف GitHub على ملف الأتمتة، يجب وضعه في مسار محدد داخل المستودع. أي خطأ في اسم المجلد أو الامتداد سيجعل المسار غير مرئي للنظام.

mkdir -p .github/workflows
touch .github/workflows/ci.yml

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

إذا كنت تبني مشروعاً يعتمد على الحاويات، فستستفيد لاحقاً من التكامل بين GitHub Actions وبين ما شرحناه في مشكلة “الكود يعمل على جهازي فقط” وكيف يحلها Docker نهائياً؟.

كتابة أول ملف Workflow خطوة بخطوة

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

name: First Workflow

on:
  push:
    branches:
      - main

jobs:
  hello:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Print welcome message
        run: echo "GitHub Actions workflow is running successfully"

كيف يقرأ GitHub هذا الملف؟

1. يراقب الحدث المحدد داخل on.
2. عند حصول push إلى main، ينشئ runner جديداً.
3. يستخدم الخطوة actions/checkout لسحب محتوى المستودع إلى بيئة التنفيذ.
4. ينفذ الأمر المحدد داخل run.

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

تطوير المسار ليشغل اختبارات فعلية

بعد فهم البنية الأساسية، تكون الخطوة الطبيعية التالية هي تشغيل اختبارات المشروع تلقائياً. هذا هو جوهر التكامل المستمر، لأنه يمنع دمج تغييرات مكسورة إلى الفرع الرئيسي، خاصة ضمن فرق تعتمد على استراتيجيات العمل الجماعي: نظام GitHub Flow وكيف تعمل الشركات الكبرى؟.

في مشروع Node.js مثلاً، يمكن تعديل workflow ليقوم بتثبيت بيئة التشغيل والاعتماديات ثم تنفيذ الاختبارات:

name: Node CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

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

أفضل الممارسات الأمنية داخل GitHub Actions

لا تضع كلمات المرور أو مفاتيح API أو بيانات SSH مباشرة داخل ملفات YAML. استخدم دائماً قسم الأسرار Secrets داخل المستودع أو المؤسسة.

فعّل سياسات حماية الفروع (Branch Protection) ومنع رفع الأكواد الخاطئة للنسخة الحية حتى لا يُسمح بدمج أي تغيير قبل نجاح الاختبارات الإلزامية. هذا الربط بين الحوكمة ونتائج الأتمتة يقلل أخطار Downtime بشكل كبير.

عند بناء صور Docker أو النشر إلى خوادم سحابية، استخدم حسابات مخصصة ذات صلاحيات دنيا Least Privilege بدلاً من حسابات إدارية واسعة الصلاحية.

كيف يرتبط Workflow بمنظومة DevOps الأوسع؟

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

هذا ينسجم مع الفلسفة التي شرحناها في مقال ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟، حيث تتحول العمليات من إجراءات يدوية معزولة إلى نظام موثوق يمكن تتبعه وتكراره عبر البيئات المختلفة.

وعندما تصل إلى مرحلة بناء الصور آلياً، سيكون من المفيد الرجوع إلى كتابة أول Dockerfile: تحويل سكربت Python إلى صورة (Image) معزولة لفهم كيف تربط عملية البناء البرمجي مع خط أنابيب النشر الحديث.

خاتمة

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

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