أتمتة مهام الروتين اليومي للمطورين باستخدام GitHub Actions

أتمتة مهام الروتين اليومي للمطورين باستخدام GitHub Actions

GitHub Actions أتمتة أصبحت من أهم الأدوات في حياة أي مطوّر يعتمد على GitHub لإدارة مشاريعه. بدلًا من تكرار نفس خطوات الاختبار، البناء، النشر، أو تنظيف المشروع يدويًا بعد كل تحديث، يمكنك إنشاء تدفقات عمل Workflows تعمل تلقائيًا عند كل دفع كود (push)، أو إنشاء طلب دمج (pull request)، أو حتى في أوقات مجدولة.

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

ما هي GitHub Actions؟ ولماذا تهمك كمطوّر؟

GitHub Actions هي منصة أتمتة مبنية داخل GitHub تسمح لك بكتابة ملفات إعداد (YAML) تصف المهام التي تريد تنفيذها، ومتى يتم تنفيذها، وعلى أي بيئة.

باختصار، GitHub Actions تسمح لك بـ:

  • أتمتة الاختبارات: تشغيل اختبارات الوحدة (Unit Tests) تلقائيًا عند كل Push أو Pull Request.
  • أتمتة البناء (Build): بناء المشروع (بايثون، Node.js، Java، إلخ) وتجهيز المخرجات (artifacts).
  • أتمتة النشر (Deploy): نشر الكود إلى خادم، حاوية Docker، أو منصة سحابية مثل AWS، DigitalOcean، وغيرها.
  • أتمتة المهام المتكررة: تنظيف فروع قديمة، تحديث Dependencies، توليد تقارير، نسخ احتياطي، إلخ.

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

كيف تعمل GitHub Actions؟ نظرة سريعة على المفاهيم الأساسية

لفهم GitHub Actions أتمتة، نحتاج لاستيعاب أربع مفاهيم رئيسية:

1. Workflow (تدفق العمل)

هو ملف YAML داخل مجلد .github/workflows/ يحتوي على تعريف متى وماذا سينفذ. يمكن أن يحتوي المستودع على أكثر من Workflow لأغراض مختلفة (اختبارات، نشر، تنظيف...).

2. Event (الحدث المحفِّز)

هو ما يحدد متى يتم تشغيل الـ Workflow، مثل:

  • push: عند دفع كود جديد إلى الفرع.
  • pull_request: عند إنشاء أو تحديث Pull Request.
  • schedule: مواعيد مجدولة (كرون).
  • workflow_dispatch: تشغيل يدوي من واجهة GitHub.

3. Job (وظيفة)

الـ Workflow يتكون من واحد أو أكثر من Jobs. كل Job يعمل في بيئة (Virtual Machine أو Container) مثل ubuntu-latest. يمكن تشغيل الـ Jobs بالتوازي أو بالتتابع.

4. Steps & Actions

  • Step: خطوة منفردة داخل Job، إما أمر Shell أو استدعاء Action.
  • Action: وحدة جاهزة قابلة لإعادة الاستخدام (من Marketplace أو من كودك) لتنفيذ مهمة معينة مثل: checkout للمستودع، إعداد بايثون، تسجيل الدخول إلى Docker، إلخ.

تهيئة أول Workflow: أتمتة الاختبارات لمشروع بايثون صغير

لنبدأ بمثال بسيط لمشروع بايثون صغير نريد أن نضمن أن اختباراته تعمل مع كل Push و Pull Request.

خطوة 1: إنشاء مجلد Workflow

داخل جذر المستودع على GitHub (أو محليًا ثم Push)، أنشئ المسار:

.github/workflows/python-tests.yml

خطوة 2: تعريف Workflow بسيط

ضع في الملف المحتوى التالي:

name: Python Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

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

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

      - name: Run tests
        run: |
          pytest

ما الذي يحدث هنا؟

  • تشغيل الـ Workflow عند كل push أو pull_request على فرع main.
  • إنشاء Job اسمه test يعمل على ubuntu-latest.
  • استخدام Action جاهزة actions/checkout لسحب الكود.
  • استخدام actions/setup-python لتجهيز بيئة بايثون.
  • تثبيت المتطلبات من requirements.txt إن وجدت.
  • تشغيل pytest لتشغيل الاختبارات.

بهذه البساطة تحوّل خطوة تشغيل الاختبارات المملة إلى عملية أوتوماتيكية ومضمونة في كل تعديل.

أتمتة البناء (Build) لمشاريع صغيرة ومتوسطة

الخطوة التالية في GitHub Actions أتمتة هي بناء المشروع وإخراج نسخة جاهزة للنشر. لنفترض أن لديك مشروع بايثون يصدر حزمة (Package) أو ملف Wheel. 

name: Build Package

on:
  push:
    tags:
      - 'v*.*.*'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install build tools
        run: |
          python -m pip install --upgrade pip
          pip install build

      - name: Build package
        run: python -m build

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist/*

في هذا السيناريو:

  • الـ Workflow يعمل فقط عند دفع Tag جديد بشكل فورمات vX.Y.Z (إصدارات).
  • يتم بناء الحزمة بواسطة python -m build.
  • يتم رفع ملفات البناء (Wheel وTar.gz) كـ Artifacts ضمن صفحة الـ Workflow في GitHub لتتمكن من تحميلها.

هذه الطريقة مناسبة للمكتبات والأدوات التي تحتاج بناء عند كل إصدار.

أتمتة النشر (Deploy) كجزء من CI/CD

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

مثال: نشر تطبيق بايثون (FastAPI أو Django) باستخدام Docker

إذا كنت تستخدم Docker – وقد شرحنا أساسياته في مقال تعلم الدوكر: شرح أساسيات التعامل مع الحاويات – يمكنك بناء الصورة (Image) تلقائيًا وإرسالها إلى Registry عند كل تحديث للفرع الرئيسي. 

name: Build and Push Docker Image

on:
  push:
    branches: [ main ]

jobs:
  docker:
    runs-on: ubuntu-latest

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

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: your-username/your-app:latest

ملاحظات مهمة:

  • تخزن بيانات الدخول (اسم المستخدم وToken) في GitHub Secrets ولا توضع أبدًا في الملف نفسه.
  • بعد دفع الصورة إلى Docker Hub، يمكن لخادم الإنتاج سحب أحدث نسخة تلقائيًا (بواسطة Webhook أو GitOps أو سكربت بسيط).

أتمتة مهام متكررة أخرى داخل المشروع

ليست GitHub Actions أتمتة مقتصرة على اختبار/بناء/نشر فقط. يمكنك أتمتة عدد كبير من المهام الروتينية التي كانت تأخذ وقتًا من يومك كمطور.

1. تشغيل مهام مجدولة (Cron Jobs)

مثال: توليد تقرير يومي عن حالة الاختبارات أو تحديث Dependencies. 

name: Daily Maintenance

on:
  schedule:
    - cron: '0 3 * * *'  # يوميًا الساعة 03:00 UTC

jobs:
  maintenance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run maintenance script
        run: |
          python scripts/daily_maintenance.py

يمكنك كتابة سكربت بايثون داخل مجلد scripts/ للتنظيف أو إرسال تقرير بالبريد أو تحديث ملف معين.

2. تنسيق الكود (Code Formatting) تلقائيًا

لجعل الكود موحّد الأسلوب، يمكن تفعيل أداة مثل black أو prettier على Pull Requests: 

name: Lint and Format

on:
  pull_request:
    branches: [ main ]

jobs:
  lint:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install tools
        run: |
          pip install black flake8

      - name: Run flake8
        run: flake8 .

      - name: Check formatting with black
        run: black --check .

بهذه الطريقة تمنع دمج كود غير منسّق أو مليء بالأخطاء النمطية في الفرع الرئيسي.

3. تنظيف الفروع القديمة (Branch Cleanup)

في مشاريع متوسطة بها عدد كبير من الـ Feature Branches، يمكن استخدام GitHub Actions لحذف الفروع التي تم دمجها بعد مدة معينة. هناك Actions جاهزة في Marketplace لهذا الغرض، أو يمكنك كتابة سكربت يستخدم GitHub API لتنفيذ ذلك.

هيكلة Workflows لمشاريع صغيرة ومتوسطة

للمشاريع الصغيرة والمتوسطة، يفضّل عدم تضخيم ملف واحد بـ Workflow شامل لكل شيء، بل تقسيم الأتمتة إلى Workflows مستقلة واضحة:

  • tests.yml: مسؤول عن الاختبارات على Push و Pull Request.
  • build.yml: مسؤول عن البناء عند الإصدارات أو عند التحديث على فرع محدد.
  • deploy.yml: مسؤول عن النشر إلى بيئة Staging أو Production.
  • maintenance.yml: مهام مجدولة للتنظيف والتقارير.

هذا التنظيم يوفر:

  • سهولة قراءة وفهم ما يحدث في كل جزء من المشروع.
  • إمكانية إعادة تشغيل جزء معين (مثل النشر فقط) بدون إعادة الاختبارات كاملة.
  • مرونة في تعديل منطق كل جزء دون كسر الباقي.

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

1. الاعتماد على Secrets والبيانات الآمنة

أي مفاتيح API، Tokens، Passwords يجب أن توضع في Settings → Secrets and variables → Actions، ثم تستخدم في الـ Workflow هكذا: 

env:
  API_TOKEN: ${{ secrets.MY_API_TOKEN }}

ولا توضع أبدًا داخل الكود الصريح أو ملفات YAML.

2. تقليل وقت التنفيذ والتكلفة

  • لا تشغل نفس الاختبارات على كل الفروع إن لم تكن بحاجة لذلك.
  • استخدم paths داخل on.push لتشغيل الـ Workflow فقط عند تغيير ملفات معينة.
on:
  push:
    branches: [ main ]
    paths:
      - 'backend/**'
      - '.github/workflows/tests.yml'

3. استخدام الـ Caching لحزم Dependencies

لتسريع البناء والاختبارات، يمكن تخزين حزم بايثون أو Node في Cache: 

- name: Cache pip
  uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
    restore-keys: |
      ${{ runner.os }}-pip-

بهذا تختصر وقت تثبيت الحزم في كل تشغيل.

ربط GitHub Actions بمفاهيم GitOps وCI/CD

في مقال GitOps باختصار: كيف تجعل Git مدير البنية التحتية شرحنا كيف يصبح Git هو “المصدر الوحيد للحقيقة” للبنية التحتية والتطبيق. GitHub Actions يكمل هذه الصورة:

  • التطبيق: يُبنى ويختبر ويُنشر تلقائيًا عند تحديث الكود.
  • البنية التحتية: يمكن تخزين ملفات Terraform أو ملفات Kubernetes Manifests داخل نفس المستودع وكتابة Workflows تقوم بتطبيق التغييرات تلقائيًا عند كل Merge.

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

خطوات عملية لتطبيق GitHub Actions أتمتة في مشروعك

  1. ابدأ بالاختبارات أولًا:
    • أنشئ Workflow بسيط للاختبارات على Pull Requests.
    • تأكد أن كل طلب دمج لا يمر إلا باختبارات خضراء.
  2. أضف مرحلة البناء (Build):
    • إن كان لديك عملية Build (Docker، حزمة، Frontend)، أتمتها على فرع رئيسي أو عند الإصدارات.
  3. فعّل النشر التلقائي بحذر:
    • ابدأ بنشر إلى بيئة Staging.
    • ثم أضف موافقة يدوية قبل النشر إلى Production باستخدام environments وrequired reviewers.
  4. أتمت المهام الثانوية:
    • تنسيق الكود، تنظيف الفروع، توليد التقارير، تحديث الوثائق.

خلاصة

GitHub Actions أتمتة ليست مجرد أداة إضافية، بل أصبحت جزءًا أساسيًا من دورة حياة التطوير الحديثة. من خلال بضعة ملفات YAML منظمة، يمكنك:

  • ضمان أن كل كود جديد يمر باختبارات صارمة بدون تدخل يدوي.
  • إخراج نسخ جاهزة للنشر بضغطة زر أو بمجرد إنشاء Tag.
  • نشر تطبيقاتك إلى الخوادم أو السحابة بطريقة متكررة وآمنة.
  • التخلص من عدد كبير من المهام الروتينية التي تستهلك وقتك اليومي.

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

حول المحتوى:

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

هل كان هذا مفيدًا لك؟

أضف تعليقك