GitHub Actions 2025: أتمتة كل شيء قبل أن يسرق وقتك

في آخر مشروع لي مع فريق Shopify، كان لدينا مشكلة حقيقية: كل مرة نضغط على زر merge في الـ pull request، يبدأ سيرفر CI/CD في الدوران لمدة 22 دقيقة كاملة. ليس لأن الكود معقد، بل لأننا كنا ننفذ 17 خطوة يدوية بدءاً من تحديث الـ npm packages وصولاً إلى تشغيل اختبارات الـ end-to-end على 5 متصفحات مختلفة. المشكلة الحقيقية؟ هذه الدقائق الـ 22 كانت تتحول إلى ساعات من الانتظار الجماعي كل أسبوع، والمطورون إما ينتظرون أو يشتتون انتباههم بمهام أخرى. هذا بالضبط ما يجعل GitHub Actions ليس مجرد أداة، بل ضرورة هندسية في 2025.

الحقيقة التي لا يريد أحد أن يعترف بها: معظم فرق التطوير تهدر 30% من وقتهم في مهام متكررة يمكن أتمتتها. ليس لأن المطورين كسالى، بل لأن الـ context switching بين كتابة الكود وتشغيل الاختبارات يدوياً يستهلك طاقة ذهنية هائلة. GitHub Actions يحل هذه الأزمة من خلال تحويل الـ repository الخاص بك إلى سيرفر ذكي ينفذ المهام قبل حتى أن تفكر فيها. لكن الأهم من ذلك: كيف تعمل هذه الأداة خلف الكواليس؟ وكيف يمكنك استغلالها لتوفير وقت حقيقي بدلاً من مجرد إضافة طبقة أخرى من التعقيد؟

كيف يعمل GitHub Actions تحت الغطاء؟

عندما تضغط على زر push في GitHub، يحدث أكثر من مجرد نقل ملفات إلى السيرفر. GitHub يستقبل الـ event هذا ويرسله إلى نظام الـ event-driven الخاص به، والذي بدوره ينشط الـ workflow المحدد في ملف YAML داخل مجلد .github/workflows. لكن التفاصيل التقنية هي ما تهم: GitHub لا يشغل الـ workflow على سيرفراته الخاصة فقط، بل يستخدم تقنية الـ ephemeral containers - أي حاويات Docker مؤقتة تُنشأ خصيصاً لتنفيذ المهمة ثم تُدمر فور انتهائها. هذا يعني أنك لست مقيداً بموارد ثابتة، بل يمكنك تشغيل مهام تتطلب 32 نواة معالجة و128 جيجابايت رام إذا احتجت لذلك.

الجانب المثير للاهتمام هو كيف يتعامل GitHub Actions مع الـ concurrency. افتراضياً، كل workflow يعمل في بيئة معزولة، لكن يمكنك التحكم في ذلك عبر الـ concurrency groups. مثلاً، إذا كان لديك workflow لتشغيل اختبارات الواجهة الأمامية وآخر للواجهة الخلفية، يمكنك جعلهما يعملان بالتوازي دون تداخل. لكن الحذر هنا مطلوب: إذا لم تحدد الـ concurrency بشكل صحيح، قد ينتهي بك الأمر مع 10 حاويات Docker تعمل في نفس الوقت تستهلك كل الـ credits الخاصة بك في دقائق معدودة.

# مثال على workflow متوازٍ مع تحكم في الـ concurrency
name: CI Pipeline

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

concurrency:
 group: ${{ github.workflow }}-${{ github.ref }}
 cancel-in-progress: true

jobs:
 frontend-tests:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with:
 node-version: 20
 - run: npm ci
 - run: npm test

 backend-tests:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-python@v5
 with:
 python-version: '3.11'
 - run: pip install -r requirements.txt
 - run: pytest

الأتمتة الذكية: أكثر من مجرد CI/CD

الخطأ الشائع هو اعتبار GitHub Actions مجرد بديل لـ Jenkins أو CircleCI. الحقيقة أنه أداة أتمتة كاملة يمكنها التعامل مع مهام لا علاقة لها بالبناء أو الاختبارات. مثلاً، في مشروع مفتوح المصدر عملت عليه، استخدمنا GitHub Actions لمراقبة الـ security vulnerabilities في الـ dependencies تلقائياً. كل ليلة، كان workflow يعمل على فحص الـ package.json و requirements.txt باستخدام أداة مثل Dependabot، وإذا وجد ثغرة أمنية، يقوم تلقائياً بإنشاء pull request مع التحديث المطلوب. هذا النوع من الأتمتة يوفر ساعات من العمل اليدوي ويقلل الأخطاء البشرية بشكل كبير.

لكن الأتمتة الحقيقية تأتي عندما تبدأ في ربط الـ workflows ببعضها البعض. مثلاً، يمكنك إنشاء workflow يعمل عند كل merge إلى الفرع الرئيسي، يقوم ببناء التطبيق، ثم ينشره إلى بيئة staging، ثم يرسل إشعاراً إلى Slack، ثم يقوم بتشغيل اختبارات الأداء باستخدام k6. المفتاح هنا هو استخدام الـ outputs من كل job كمدخلات للـ job التالية. المشكلة التي واجهناها في البداية هي أن الـ outputs كانت تختفي بعد انتهاء الـ job، لذلك اضطررنا لاستخدام الـ artifacts لحفظ البيانات بين الـ jobs.

name: Deployment Pipeline

on:
 push:
 branches: [ main ]

jobs:
 build:
 runs-on: ubuntu-latest
 outputs:
 image-tag: ${{ steps.build.outputs.tag }}
 steps:
 - uses: actions/checkout@v4
 - id: build
 run: |
 TAG=$(date +%s)
 docker build -t myapp:$TAG .
 echo "tag=$TAG" >> $GITHUB_OUTPUT

 deploy:
 needs: build
 runs-on: ubuntu-latest
 steps:
 - name: Deploy to Staging
 run: |
 echo "Deploying image myapp:${{ needs.build.outputs.image-tag }}"
 # أوامر النشر الفعلية هنا

 performance-test:
 needs: deploy
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - run: npm install -g k6
 - run: k6 run --vus 10 --duration 30s tests/performance.js

الفخاخ التي يقع فيها حتى المحترفون

أول فخ كبير هو تجاهل الـ secrets management. كثير من المطورين يضعون الـ secrets مباشرة في ملفات YAML، وهذا خطأ أمني جسيم. GitHub يوفر نظام secrets آمن، لكن المشكلة الحقيقية تأتي عندما تحتاج لتمرير الـ secrets بين الـ jobs. الحل هو استخدام الـ encrypted secrets مع الـ environment variables، لكن حتى هذا له حدود: إذا كان لديك workflow مع 10 jobs، قد ينتهي بك الأمر مع 10 نسخ من نفس الـ secret في الذاكرة، وهذا يزيد من خطر الـ memory leaks إذا لم يتم التعامل معها بعناية.

الفخ الثاني هو تجاهل الـ caching. في مشروع عملت عليه، كان لدينا workflow يستغرق 15 دقيقة فقط لبناء الـ Docker image، لكن 12 دقيقة منها كانت تذهب في تحميل الـ dependencies. الحل كان استخدام الـ caching بشكل ذكي. المشكلة هي أن معظم الأمثلة على الإنترنت تستخدم الـ caching بشكل سطحي، لكن الحل الفعال يتطلب فهم كيفية عمل الـ layer caching في Docker وكيفية استخدام الـ actions/cache بشكل صحيح. مثلاً، يمكنك تخزين مجلد node_modules بين الـ runs، لكن إذا لم تحدد الـ cache key بشكل صحيح، قد ينتهي بك الأمر مع نسخة قديمة من الـ dependencies.

# مثال على caching فعال
jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with:
 node-version: 20
 - name: Cache node modules
 uses: actions/cache@v3
 id: cache
 with:
 path: node_modules
 key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
 restore-keys: |
 ${{ runner.os }}-node-
 - run: npm ci
 if: steps.cache.outputs.cache-hit != 'true'

الأتمتة المتقدمة: عندما يصبح GitHub Actions ذكياُ

في Netflix، يستخدمون GitHub Actions بطريقة مختلفة تماماً. بدلاً من مجرد تشغيل الاختبارات عند كل push، لديهم نظام ذكي يحدد أي أجزاء من الكود تغيرت ويقوم بتشغيل اختبارات محددة فقط. مثلاً، إذا غيرت ملفاً في مجلد frontend، فلن يتم تشغيل اختبارات الـ backend. هذا النوع من الأتمتة الذكية يتطلب استخدام الـ path filters مع فهم عميق لهيكلية المشروع. المشكلة التي واجهناها عند تطبيق هذا هي أن الـ path filters لا تعمل بشكل جيد مع الـ monorepos الكبيرة، لذلك اضطررنا لاستخدام أداة خارجية مثل Turborepo لتحديد الـ affected packages.

الخطوة التالية هي استخدام الـ matrix strategy لتشغيل نفس الـ job على بيئات مختلفة. مثلاً، يمكنك تشغيل اختبارات الواجهة الأمامية على 5 إصدارات مختلفة من Node.js و3 متصفحات مختلفة في نفس الوقت. لكن الحذر هنا مطلوب: إذا لم تحدد الـ matrix بشكل صحيح، قد ينتهي بك الأمر مع 15 job تعمل في نفس الوقت، وهذا قد يستهلك كل الـ credits الخاصة بك بسرعة. الحل هو استخدام الـ max-parallel لتحديد عدد الـ jobs المتوازية.

jobs:
 test:
 runs-on: ubuntu-latest
 strategy:
 matrix:
 node-version: [18, 20, 22]
 browser: [chrome, firefox, safari]
 max-parallel: 3
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with:
 node-version: ${{ matrix.node-version }}
 - run: npm ci
 - run: npm test -- --browser=${{ matrix.browser }}

الـ Troubleshooting: عندما يفشل كل شيء

عندما يفشل workflow في GitHub Actions، قد يكون من الصعب جداً معرفة السبب. المشكلة الأكبر هي أن الـ logs قد تكون غير واضحة أو مختصرة جداً. مثلاً، قد ترى رسالة خطأ تقول "Process completed with exit code 1" دون أي تفاصيل إضافية. الحل هنا هو استخدام الـ debug mode، الذي يمكنك تفعيله عبر إضافة متغير بيئة RUNNER_DEBUG=true. هذا سيعطيك تفاصيل أكثر عن ما يحدث داخل الـ container، بما في ذلك الـ system calls والـ memory usage.

فخ آخر هو تجاهل الـ timeout. افتراضياً، كل job في GitHub Actions له timeout مدته 6 ساعات. لكن في بعض الأحيان، قد تعلق الـ job دون أن تفشل، وهذا قد يستهلك الـ credits دون فائدة. الحل هو تحديد timeout محدد لكل job باستخدام الـ timeout-minutes. مثلاً، إذا كنت تعلم أن اختباراتك تستغرق عادة 10 دقائق، يمكنك تحديد timeout مدته 15 دقيقة لتجنب أي مشاكل.

jobs:
 test:
 runs-on: ubuntu-latest
 timeout-minutes: 15
 steps:
 - uses: actions/checkout@v4
 - run: npm ci
 - run: npm test
 timeout-minutes: 10

خلاصة المهندس: نصائح لا تقدر بثمن

إذا كنت تريد أن تبدأ مع GitHub Actions اليوم، فهذه هي النصائح التي ستوفر عليك أشهراً من التجربة والخطأ: أولاً، ابدأ بمهام بسيطة مثل تشغيل الاختبارات عند كل push، ثم انتقل تدريجياً إلى مهام أكثر تعقيداً. ثانياً، استخدم الـ caching دائماً - حتى لو كان مشروعك صغيراً، لأنك ستندهش من مقدار الوقت الذي يمكن توفيره. ثالثاً، راقب استخدام الـ credits الخاص بك عن كثب، لأن الـ workflows المتوازية يمكن أن تستهلكها بسرعة. رابعاً، استثمر وقتاً في فهم الـ secrets management بشكل صحيح، لأن خطأ واحداً هنا يمكن أن يعرض مشروعك بالكامل للخطر.

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

الأتمتة ليست مجرد توفير الوقت، بل هي إعادة تعريف الطريقة التي نعمل بها. عندما تتمكن من تشغيل 100 اختبار في 5 دقائق بدلاً من 5 ساعات، تبدأ في التفكير بشكل مختلف تماماً عن الجودة والكفاءة.

— مارغريت هاملتون، مهندسة برمجيات في ناسا