GitHub Actions چیست؛ پایپلاین‌های CI/CD و اتوماسیون

GitHub Actions چیست؟

GitHub Actions یک پلتفرم اتوماسیون جریان کار ساخته شده در GitHub است که در سال 2019 راه‌اندازی شد. آن به شما امکان تعریف پایپلاین‌های CI/CD را در فایل‌های YAML که مستقیماً در رپوزیتوری ذخیره می‌شوند را می‌دهد. هر workflow توسط یک تریگر اجرا می‌شود: push، pull request، ایجاد تگ یا بر اساس زمان‌بندی. بر خلاف Jenkins یا TeamCity، به زیرساخت جداگانه برای میزبانی سرور CI نیاز نیست.

در بزگ توسعه اپلیکیشن موبایل، GitHub Actions کامپایل APK و IPA، اجرای تست‌های واحد و واسط کاربر روی شبیه‌سازها، بررسی کد توسط لینترها، امضا و انتشار در 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 رانرهای میزبانی شده با سیستم‌عامل‌های از پیش نصب شده ارائه می‌دهد: Ubuntu، macOS و Windows. برای کامپایل iOS رانر macOS و برای Android رانر Linux یا macOS ضروری است. Self-hosted runner‌ها به شما امکان اجرای کارها روی سرورهای خود را با محیط سفارشی می‌دهند که برای پروژه‌های بزرگ با نیازهای سخت‌افزاری خاص مفید است. GitHub همچنین از گروه‌های self-hosted runner برای ساماندهی صف اجرای کارها پشتیبانی می‌کند.

ساختار فایل 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 رانر 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). این تایید سازگاری اپلیکیشن را با نسخه‌های مختلف سیستم‌عامل سرعت می‌بخشد، هرچند مصرف دقایق رانرها را افزایش می‌دهد. برای پروژه‌هایی با بودجه CI محدود، می‌توان ماتریس را فقط به تنظیمات اصلی محدود کرد.

راه‌اندازی محیط برای Android

GitHub Actions اکشن setup-java را برای نصب JDK و caching را برای ذخیره‌سازی Gradle فراهم می‌کند. Android SDK از قبل روی رانرهای Ubuntu نصب شده است. برای سطوح API سفارشی، sdkmanager در یک step جداگانه استفاده می‌شود. توصیه می‌شود یک workflow جداگانه برای کامپایل Android و iOS ایجاد کنید، زیرا آنها از رانرها و ابزارهای کامپایل متفاوتی استفاده می‌کنند.

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، تنظیم کار با شبیه‌سازها و دستگاه‌ها به صورت صحیح مهم است. رانر macOS-14 محیطی با Rosetta 2 برای اجرای کامپایل‌های Intel روی معماری ARM فراهم می‌کند. Workflow می‌تواند چند شمات کامپایل را شامل شود — Debug برای pull request و Release برای تگ‌ها. GitHub Actions از تجزیه و تحلیل xcresult از طریق اکشن xcparse/sonarqube برای نمایش نتایج تست پشتیبانی می‌کند. برای ارسال اطلاع‌رسانی درباره وضعیت کامپایل، می‌توان اکشن Slack یا Telegram را اضافه کرد.

Code signing برای iOS نیازمند واردات گواهی‌نامه‌ها و provisioning profiles است. Apple-actions یک step برای واردات گواهی‌نامه P12 و نصب provisioning profile فراهم می‌کند. گواهی‌نامه‌ها به عنوان اسرار GitHub Actions ذخیره می‌شوند و فقط در مرحله کامپایل رمزگشایی می‌شوند. برای اتوماسیون امضا، از Fastlane match استفاده می‌شود که می‌تواند به عنوان یک step جداگانه در 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 را با action setup-gradle از Gradle برای مدیریت بهینه ذخیره‌ها ترکیب کنید. برای وابستگی‌های npm در React Native، actions/cache با هش package-lock.json استفاده می‌شود. با تنظیم صحیح ذخیره‌سازی، می‌توان زمان کامپایل را تا 70% کاهش داد.

GitHub Actions از متغیرهای محیطی در سطوح workflow، job و step پشتیبانی می‌کند. متغیرهای محیطی قابل بازنویسی هستند: سطح step بالاترین اولویت را دارد. برای داده‌های محرمانه همیشه از اسرار استفاده کنید — آنها با AES-256 رمزگذاری شده و در سیاهه‌ها نمایش داده نمی‌شوند. قوانین حفاظت محیط نیز موجود است — تایید دستی اجباری قبل از اجرای استقرار. برای امنیت بیشتر، می‌توان تایید اجباری توسط کاربران یا تیم‌های مشخص را تنظیم کرد.

GitHub Actions همچنین از Reusable Workflows پشتیبانی می‌کند — پایپلاین‌های قابل استفاده مجدد که می‌توانند از سایر workflow‌ها فراخوانی شوند. این امکان را می‌دهد یک workflow کامپایل متمرکز ایجاد کرده و آن را در تمام رپوزیتوری‌های سازمان استفاده کرد. Reusable workflow با یک خط فراخوانی می‌شود و می‌تواند پارامترهای ورودی و اسرار را دریافت کند. این به ویژه برای استانداردسازی رویه‌های CI/CD در تیم‌های بزرگ مفید است.

امنیت و بهترین رویه‌ها

در تنظیم GitHub Actions برای پروژه‌های موبایل، پیروی از اصول امنیت مهم است. OIDC (OpenID Connect) به شما امکان عدول از اعتبارنامه‌های دائمی و دریافت توکن‌های موقت برای ارائه‌دهندگان ابری را می‌دهد. هرگز از اسرار به صورت متن ساده در اسکریپت‌ها استفاده نکنید — GitHub Actions به طور اتوماتیک اسرار را در سیاهه‌ها پوشش می‌دهد.

برای پروژه‌های موبایل، محدود کردن دسترسی workflow برای fork‌های شخص ثالث اهمیت بالایی دارد. از تنظیم pull_request_target با احتیاط استفاده کنید — آن کد را از شاخه اصلی اجرا می‌کند، نه از fork. برای code signing اپلیکیشن‌های iOS، توصیه می‌شود گواهی‌نامه‌ها را به صورت رمزگذاری شده ذخیره کرده و فقط در مرحله کامپایل توسط gpg یا openssl رمزگشایی کنید.