GitHub Actions — ما هو، خطوط أنابيب CI/CD والأتمتة

ما هو GitHub Actions؟

GitHub Actions هي منصة أتمتة سير العمل المدمجة في GitHub والتي أُطلقت في عام 2019. تتيح لك تعريف خطوط أنابيب CI/CD في ملفات YAML المخزنة مباشرة في المستودع. يتم تشغيل كل workflow بواسطة حدث: push أو pull request أو إنشاء tag أو وفقًا لجدول زمني. على عكس Jenkins أو TeamCity، لا تتطلب بنية تحتية منفصلة لاستضافة خادم CI.

في سياق تطوير التطبيقات المحمولة، تقوم GitHub Actions بأتمتة بناء APK و IPA، وتشغيل اختبارات الوحدة واختبارات UI على المحاكيات، وفحص الكود باستخدام linters، والتوقيع والنشر في Google Play و App Store. توفر المنصة دقائق مجانية للمستودعات العامة وللخاصة حسب الخطة التعريفية. بالنسبة لمشاريع المصدر المفتوح المحمولة، فهذا حل CI/CD كامل بدون تكلفة.

هندسة GitHub Actions: Workflows و Jobs و Steps

تتكون هندسة GitHub Actions من أربعة مستويات. Workflow هو ملف YAML الجذر الذي يحدد الأتمتة. يتكون Workflow من Jobs، كل Job يتم تنفيذه على Runner منفصل. داخل Job يتم تنفيذ Steps — أوامر متسلسلة أو إجراءات خارجية. تحدد Events المشغلات: push و pull_request و schedule و workflow_dispatch. يمكن أيضًا تشغيل workflow يدويًا من خلال علامة التبويب Actions في واجهة GitHub.

توفر GitHub runners مستضافة مع أنظمة تشغيل مثبتة مسبقًا: Ubuntu و macOS و Windows. لبناء iOS، يجب استخدام runner macOS، ولـ Android — Linux أو macOS. تتيح self-hosted runners تشغيل jobs على خوادمك الخاصة ببيئة مخصصة، وهو مفيد للمشاريع الكبيرة ذات المتطلبات الخاصة للأجهزة. تدعم GitHub أيضًا مجموعات self-hosted runners لتنظيم قوائم انتظار تنفيذ jobs.

هيكل ملف workflow

يحتوي ملف workflow الأساسي على أقسام: name و on (المشغلات) و jobs. يحدد كل job runs-on (نوع runner) و strategy (مصفوفة) و steps (قائمة إجراءات). يمكن أن تكون Steps أوامر shell أو إجراءات جاهزة من السوق، متصلة باستخدام الصيغة owner/repo@version.

بناء التطبيقات المحمولة في GitHub Actions

لبناء Android، يتضمن workflow عادةً خطوات: checkout المستودع، تثبيت JDK، تكوين ذاكرة التخزين المؤقت لـ Gradle، تشغيل assembleRelease. لـ iOS يتطلب runner macOS، تثبيت Xcode عبر xcode-select، حل provisioning profile وتشغيل xcodebuild. يكمن تعقيد بناء iOS في code signing وإدارة الشهادات. تشمل الإعدادات الخاصة بـ Apple إدارة provisioning profile عبر apple-actions/import-codesign-certs.

تتيح Matrix strategy تشغيل البناء على إصدارات متعددة في وقت واحد. على سبيل المثال: مصفوفة بإصدارات iOS (15.0، 16.0، 17.0) و Xcode (14، 15). هذا يسرع التحقق من توافق التطبيق مع إصدارات مختلفة من نظام التشغيل، على الرغم من أنه يزيد من استهلاك دقائق runners. للمشاريع ذات ميزانية CI محدودة، يمكن تقييد المصفوفة بالتكوينات الرئيسية فقط.

إعداد البيئة لـ Android

توفر GitHub Actions إجراء setup-java لتثبيت JDK و caching لتخزين Gradle مؤقتًا. Android SDK مثبت مسبقًا على runners Ubuntu. لمستويات API المخصصة، يُستخدم sdkmanager في خطوة منفصلة. يُوصى بإنشاء workflows منفصلة لبناء Android و iOS، حيث يستخدمان runners وأدوات بناء مختلفة.

GitHub Marketplace والإجراءات الجاهزة

يحتوي GitHub Marketplace على أكثر من 15,000 إجراء تم إنشاؤها بواسطة المجتمع والمطورين الرسميين. لتطوير التطبيقات المحمولة، تشمل الفئات الرئيسية: Code signing (apple-actions/import-codesign-certs)، الاختبار (react-native-community/action)، النشر (google-github-actions/release-google-play)، الإشعارات (slackapi/slack-github-action). تتوفر أيضًا إجراءات لـ Firebase App Distribution و TestFlight upload و Fastlane. كل إجراء له علامة توافق مع نظام تشغيل runner معين.

كل إجراء له إصدار ووصف و README وترخيص. عند اختيار إجراء، يُفضل استخدام الإجراءات الرسمية من البائعين (Google و Apple و Microsoft) والتي تم التحقق منها عبر Verified Badge. من المهم تحديد إصدار رئيسي ثابت (actions/checkout@v4)، وليس @main، لتجنب التغييرات غير المتوقعة. إذا لم يكن الإجراء المطلوب موجودًا في Marketplace، يمكنك إنشاء إجراء مخصص — محليًا في المستودع (Docker action أو JavaScript action) أو نشره في Marketplace.

الإجراءات الشائعة لـ CI/CD المحمول

• actions/checkout — يستنسخ المستودع إلى runner
• actions/setup-java — يثبت JDK لبناء Android
• gradle/actions/setup-gradle — يهيئ ويخزن Gradle مؤقتًا
• apple-actions/import-codesign-certs — يستورد الشهادات لـ iOS
• google-github-actions/submit-release — ينشر في Google Play Console

مثال workflow لمشروع iOS

عند تطوير تطبيقات iOS، من المهم إعداد العمل الصحيح مع المحاكيات والأجهزة. يوفر runner macOS-14 بيئة مع Rosetta 2 لتشغيل بنيات Intel على بنية ARM. يمكن أن يتضمن workflow مخططات بناء متعددة — Debug لطلبات السحب و Release للعلامات. يدعم GitHub Actions تحليل xcresult من خلال إجراء xcparse/sonarqube لعرض نتائج الاختبار. لإرسال إشعارات حالة البناء، يمكن إضافة إجراء Slack أو Telegram.

يتطلب code signing لـ iOS استيراد الشهادات و provisioning profiles. توفر Apple-actions خطوة لاستيراد شهادة P12 وتثبيت provisioning profile. تُخزّن الشهادات كـ secrets في GitHub Actions ويتم فك تشفيرها فقط في مرحلة البناء. لأتمتة التوقيع، يُستخدم Fastlane match، والذي يمكن استدعاؤه كخطوة منفصلة في workflow.

لننظر في workflow لتطبيق iOS بلغة Swift يقوم ببناء المشروع وتشغيل الاختبارات وإنشاء بناء مؤرشَف. يستخدم workflow runner macOS-14 و Xcode 15.4 وإجراءات لإدارة الشهادات.

name: iOS CI

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

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

تخزين التبعيات المؤقت في GitHub Actions

يقلل التخزين المؤقت من وقت البناء عن طريق الحفاظ على التبعيات بين عمليات تشغيل workflow. توفر GitHub تخزينًا مؤقتًا مدمجًا عبر actions/cache. لـ Gradle، يتم تخزين ~/.gradle مؤقتًا، لـ CocoaPods — Pods/، لـ SPM — .build/. يتضمن مفتاح التخزين المؤقت تجزئة لملف قائمة التبعيات — عندما تتغير التبعيات، يتم إبطال التخزين المؤقت تلقائيًا.

يجب إيلاء اهتمام خاص لاستراتيجية استعادة التخزين المؤقت (restore-keys). إذا لم يتم العثور على المفتاح الدقيق، يحاول GitHub Actions المطابقة الجزئية عبر restore-keys. هذا مفيد عندما تتغير تبعية واحدة فقط — يظل التخزين المؤقت قابلًا للاستخدام جزئيًا. لـ Gradle، يُوصى أيضًا بتمكين Gradle Build Cache، الذي يخزن نتائج البناء بين وحدات المشروع المختلفة.

مثال تخزين Gradle المؤقت

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

كفاءة التخزين المؤقت لمشاريع Android: البناء الأول بدون تخزين مؤقت — 8–12 دقيقة، البناء اللاحق مع التخزين المؤقت — 2–4 دقائق. لـ iOS مع CocoaPods، التوفير مماثل. يُوصى بدمج actions/cache مع إجراء setup-gradle من Gradle لإدارة مثلى للتخزين المؤقت. لتبعيات npm في React Native، يُستخدم actions/cache مع تجزئة package-lock.json. مع التكوين المناسب للتخزين المؤقت، يمكن تقليل وقت البناء بنسبة تصل إلى 70%.

تدعم GitHub Actions متغيرات البيئة على مستوى workflow و job و step. يمكن تجاوز متغيرات البيئة: مستوى step له الأولوية القصوى. للبيانات السرية، استخدم دائمًا secrets — فهي مشفرة بـ AES-256 ولا تظهر في السجلات. تتوفر أيضًا قواعد حماية البيئة — موافقة يدوية إلزامية قبل النشر. لمزيد من الأمان، يمكن تكوين موافقة إلزامية من مستخدمين أو فرق محددة.

تدعم GitHub Actions أيضًا Reusable Workflows — خطوط أنابيب قابلة لإعادة الاستخدام يمكن استدعاؤها من workflows أخرى. هذا يسمح بإنشاء workflow بناء مركزي وإعادة استخدامه عبر جميع مستودعات المؤسسة. يتم استدعاء reusable workflow بسطر واحد ويمكنه قبول معلمات إدخال و secrets. هذا مفيد بشكل خاص لتوحيد ممارسات CI/CD في الفرق الكبيرة.

الأمان وأفضل الممارسات

عند تكوين GitHub Actions لمشاريع المحمول، من المهم اتباع مبادئ الأمان. OIDC (OpenID Connect) يسمح بالتخلص من بيانات الاعتماد طويلة العمر والحصول على رموز مؤقتة لمزودي الخدمات السحابية. لا تستخدم أبدًا secrets كنص عادي في البرامج النصية — يقوم GitHub Actions تلقائيًا بإخفاء secrets في السجلات.

لمشاريع المحمول، من الضروري تقييد الوصول إلى workflow للـ forks الخارجية. استخدم إعداد pull_request_target بحذر — فهو ينفذ كودًا من الفرع الأساسي، وليس من fork. لتوقيع كود تطبيقات iOS، يُوصى بتخزين الشهادات مشفرة وفك تشفيرها فقط في مرحلة البناء عبر gpg أو openssl.