شرح GitHub Actions للمبتدئين: ما هي وكيف تستخدم في CI/CD؟

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

كل مرة يحدث فيها تعديل، قد تحتاج إلى تنفيذ مجموعة من الخطوات:

• تثبيت الـDependencies.
• بناء المشروع.
• تشغيل الاختبارات.
• التأكد أن الكود لا يحتوي على مشاكل واضحة.
• تجهيز نسخة للنشر.
• رفع النسخة إلى Server أو Cloud.
• وربما تنفيذ خطوات أخرى قبل أو بعد النشر.

يمكنك تنفيذ كل هذه الخطوات يدويًا.

لكن ماذا يحدث عندما يعمل على المشروع أكثر من Developer؟

وماذا يحدث عندما يتم عمل عشرات التعديلات يوميًا؟

هنا تبدأ مشكلة الأتمتة.

ومن الأدوات التي تحاول حل هذه المشكلة GitHub Actions.

ما هي GitHub Actions؟

GitHub Actions هي خدمة Automation موجودة داخل GitHub.

ببساطة، تستطيع أن تقول لـGitHub:

عندما يحدث شيء معين في المشروع، نفّذ مجموعة من الخطوات تلقائيًا.

مثلًا:

عندما يقوم Developer بعمل Push للكود:

1. حمّل المشروع.
2. ابنِ التطبيق.
3. شغّل الاختبارات.
4. أخبرني هل كل شيء يعمل أم لا.

أو عندما يتم دمج Pull Request في الفرع الرئيسي:

1. جهّز نسخة Production.
2. نفّذ الاختبارات النهائية.
3. انشر النسخة الجديدة.

بدل أن يقوم شخص بتنفيذ هذه الخطوات يدويًا في كل مرة، تقوم GitHub Actions بتنفيذها بصورة آلية ومتكررة.

ما المشكلة التي تحلها؟

لنفترض أن فريقًا من ثلاثة Developers يعمل على تطبيق.

Developer قام بتعديل Feature معينة واختبرها على جهازه، ثم رفع الكود.

Developer آخر قام بتعديل جزء آخر.

وبعد دمج التغييرات اكتشف الفريق أن التطبيق لم يعد يعمل.

قد تسمع وقتها العبارة الشهيرة:

"بس هو كان شغال عندي."

المشكلة أن كل شخص كان يختبر التغيير بطريقته وعلى جهاز مختلف.

هنا يمكن أن تساعد GitHub Actions.

بدل الاعتماد على أن يتذكر كل Developer تشغيل الاختبارات، يمكن جعلها تعمل تلقائيًا عند كل Pull Request.

فلو كسر التعديل اختبارًا موجودًا، يعرف الفريق قبل دمج الكود.

وهذه واحدة من أهم الأفكار وراء Continuous Integration أو CI.

ما هو CI؟

CI اختصار لـ:

Continuous Integration

أو التكامل المستمر.

الفكرة ببساطة أن تغييرات المطورين يتم دمجها والتحقق منها باستمرار بدل الانتظار لفترات طويلة ثم محاولة دمج كمية كبيرة من التغييرات مرة واحدة.

جزء مهم من ذلك هو تشغيل عمليات تلقائية مثل:

Build → Test → Validation

كلما حدث تغيير.

لو فشل أحدها، نعرف أن هناك مشكلة قبل وصول الكود إلى Production.

GitHub Actions واحدة من الأدوات التي تستطيع تنفيذ هذه العملية.

وماذا عن CD؟

غالبًا ستجد مصطلحًا آخر بجانب CI:

CD

وقد يستخدم للإشارة إلى Continuous Delivery أو Continuous Deployment حسب طريقة العمل.

الفكرة العامة هنا هي أتمتة المراحل التي تأتي بعد التأكد من جودة الكود.

مثل:

Build → Test → Package → Deploy

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

ومن هنا يأتي المصطلح الذي ستراه كثيرًا:

CI/CD Pipeline

وهي ببساطة سلسلة من الخطوات التي يمر بها الكود من لحظة التعديل حتى يصبح جاهزًا أو منشورًا.

كيف تعرف GitHub Actions ماذا تفعل؟

عادة يتم تعريف الـWorkflow داخل ملف YAML في المشروع.

لا تحتاج في البداية إلى حفظ شكل الملف.

المهم أن تفهم الفكرة.

الـWorkflow تقول لـGitHub شيئًا مثل:

عندما يتم إنشاء Pull Request، شغّل الاختبارات.

أو:

عندما يتم Push إلى main، جهّز نسخة جديدة.

ولفهم GitHub Actions ستقابل بعض المصطلحات الأساسية.

Workflow

الـWorkflow هي العملية الكاملة التي تريد تنفيذها.

مثلًا:

اختبار Pull Request

أو:

نشر التطبيق إلى Production

ويمكن أن يحتوي المشروع على أكثر من Workflow.

Event

الـEvent هو الشيء الذي يجعل الـWorkflow تبدأ.

مثل: Push، Pull Request، إنشاء Release، تشغيل يدوي، أو Schedule يعمل في وقت محدد.

بمعنى آخر:

متى تريد تشغيل الـWorkflow؟

Job

الـWorkflow يمكن أن تحتوي على Job واحدة أو أكثر.

مثلًا يمكن أن يكون لديك Build Job وTest Job وDeploy Job، وكل Job مسؤولة عن جزء معين من العملية.

Step

داخل كل Job توجد مجموعة من الخطوات.

مثلًا Test Job قد تحتوي على:

1. تحميل الكود.
2. تثبيت الـDependencies.
3. تشغيل الاختبارات.
4. حفظ النتائج.

كل واحدة من هذه تعتبر Step.

Runner

الأوامر الموجودة في GitHub Actions يجب أن تعمل على جهاز في النهاية. هذا الجهاز يسمى Runner.

يمكن أن توفر GitHub الـRunner لك، وهذا يسمى GitHub-hosted runner، أو يمكنك تجهيز جهاز خاص بك وتشغيل الـJobs عليه، وهذا يسمى Self-hosted runner.

بالنسبة للمبتدئ، غالبًا لا تحتاج إلى التفكير في Self-hosted runners في البداية. ابدأ بما توفره GitHub، ثم انتقل للخيارات الأخرى عندما يكون لديك سبب حقيقي لذلك.

وما هي Action؟

اسم المنتج GitHub Actions لأن هناك أيضًا وحدات جاهزة لإعادة الاستخدام تسمى Actions.

بدل أن تكتب كل شيء بنفسك، يمكنك استخدام Action موجودة بالفعل لتنفيذ مهمة معينة، مثل تحميل Source Code الخاص بالمشروع أو تجهيز Runtime معين أو تنفيذ عملية Deployment.

بمعنى آخر، الـWorkflow تستطيع الجمع بين Actions جاهزة + أوامر تكتبها أنت لتكوين الـAutomation المطلوبة.

مثال بسيط

تخيل أنك تعمل على مشروع ولديك مجموعة Tests.

بدون GitHub Actions: Developer يعدل الكود، ثم يتذكر تشغيل الاختبارات، ثم ينشئ Pull Request، ثم يقوم شخص آخر بالمراجعة.

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

Developer يعدل الكود → ينشئ Pull Request → GitHub تشغل الاختبارات تلقائيًا → تظهر النتيجة → يبدأ Code Review.

بهذا أنت لم تستبدل الـDeveloper. أنت فقط أزلت خطوة متكررة كان الإنسان يقوم بها يدويًا.

هل GitHub Actions تستخدم للاختبارات فقط؟

لا. يمكن استخدامها في تشغيل Unit Tests، وعمل Build، وCode Analysis، وFormatting أو Linting، وإنشاء Packages، والنشر، وتشغيل Scripts مجدولة، والتعامل مع Issues وPull Requests، وحتى بعض Workflows المعتمدة على AI Agents.

لكن لو كنت مبتدئًا، لا تبدأ بكل ذلك. أول Workflow مفيدة لك غالبًا هي: شغّل الاختبارات تلقائيًا عند إنشاء Pull Request.

هل GitHub Actions هي الأداة الوحيدة؟

لا. مفهوم CI/CD أقدم وأكبر من GitHub Actions، وهناك أدوات كثيرة تقوم بنفس الفكرة.

GitHub Actions

موجودة داخل GitHub مباشرة. لو Source Code الخاص بك موجود بالفعل على GitHub، فهي غالبًا من أسهل الأماكن التي يمكن أن تبدأ منها.

Azure Pipelines

جزء من Azure DevOps، وتستطيع من خلالها بناء واختبار ونشر التطبيقات. فكرتها الأساسية مشابهة: Trigger → Pipeline → Jobs → Steps → Agent.

GitLab CI/CD

GitLab لديها نظام CI/CD مدمج داخل المنصة، ويتم تعريف الـPipeline عادة داخل ملف .gitlab-ci.yml، ويتم تنفيذ العمل من خلال Runners.

Bitbucket Pipelines

لو كان المشروع موجودًا على Bitbucket، ستجد خدمة Bitbucket Pipelines لبناء واختبار ونشر المشروع تلقائيًا.

Jenkins

Jenkins Automation Server مستقل نسبيًا عن منصة Git بعينها، ويمكن للفريق تشغيله وإدارته لبناء CI/CD Pipelines.

هل يجب أن أتعلم كل هذه الأدوات؟

لا. لا تبدأ بحفظ Syntax الخاصة بخمس أدوات.

افهم أولًا المفاهيم المشتركة: ما هو CI/CD؟ ما هي Pipeline؟ ما هو Trigger؟ ما هي Job؟ ما هو Runner أو Agent؟ ولماذا نشغّل الاختبارات تلقائيًا؟

إذا فهمت هذه الأشياء، الانتقال بين الأدوات يصبح أسهل كثيرًا.

المشكلة التي تحاول الأدوات حلها واحدة تقريبًا: كيف نحول خطوات تطوير وتسليم البرنامج المتكررة إلى عملية آلية يمكن تنفيذها بنفس الطريقة في كل مرة؟

أي أداة أختار؟

لو أنت مبتدئ ومشروعك موجود على GitHub، ابدأ بـGitHub Actions؛ لأنك تستطيع تعلم الفكرة بدون إضافة منصة أخرى إلى مشروعك.

بعد أن تفهم Workflow بسيطة مثل Pull Request → Build → Test، يمكنك الانتقال إلى Deployment وEnvironments وSecrets وArtifacts وCaching وSelf-hosted runners وReusable workflows.

الخلاصة

GitHub Actions هي ببساطة وسيلة لأتمتة العمل الذي يحدث حول الكود.

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

ومن هنا تبدأ فكرة CI/CD.

إذا فهمت المشكلة بهذه الطريقة، ستجد أن GitHub Actions وAzure Pipelines وGitLab CI/CD وBitbucket Pipelines وJenkins أدوات مختلفة تحاول مساعدتك في بناء الشيء نفسه تقريبًا: طريق آلي وموثوق ينتقل فيه الكود من التعديل إلى الاختبار، ثم في النهاية إلى المستخدم.