CI/CD Pipeline — چیست، مراحل اتوماسیون و ابزارها

CI/CD Pipeline چیست

CI/CD Pipeline — مجموعه‌ای رسمی و خودکار از فرآیندهایی است که کد از لحظه ثبت تغییرات در مخزن تا استقرار در محیط تولید طی می‌کند. این اصطلاح دو روش را ترکیب می‌کند: Continuous Integration (ادغام پیوسته) و Continuous Delivery (تحویل پیوسته) که با هم خط لوله تحویل نرم‌افزار را تشکیل می‌دهند.

تاریخچه پیدایش CI/CD

مفهوم Continuous Integration توسط گریدی بوچ در سال ۱۹۹۱ توصیف شد و در دهه ۲۰۰۰ توسط مارتین فاولر رایج گردید. Continuous Delivery به عنوان یک اصطلاح پس از کتاب جز هامبل و دیوید فارلی «Continuous Delivery» (۲۰۱۰) تثبیت شد. CI/CD Pipeline مدرن پس از سال ۲۰۱۵ با ظهور سرورهای CI ابری و اتوماسیون فروشگاه‌های اپلیکیشن به استاندارد عملی در توسعه اپلیکیشن‌های موبایل تبدیل شد.

چرا CI/CD Pipeline در توسعه اپلیکیشن‌های موبایل ضروری است

اپلیکیشن‌های موبایل نیازهای خاصی برای ساخت و انتشار دارند: امضا با گواهی‌ها، چندین پیکربندی (debug، release، staging)، مبهم‌سازی با ProGuard/R8، انواع مختلف بیلد (APK، AAB، IPA) و یکپارچه‌سازی با فروشگاه‌های اپلیکیشن. انجام دستی این مراحل ساعت‌ها زمان می‌برد و مستعد خطا است — CI/CD Pipeline کارهای تکراری را خودکار می‌کند.

مراحل CI/CD Pipeline برای اپلیکیشن‌های موبایل

CI/CD Pipeline استاندارد برای اپلیکیشن Android یا iOS از هفت مرحله کلیدی تشکیل شده است. برخی مراحل به صورت موازی و برخی دیگر به صورت ترتیبی اجرا می‌شوند. ترکیب دقیق مراحل به پشته فناوری و بلوغ تیم بستگی دارد، اما هسته ثابت می‌ماند.

۱. Checkout و نصب وابستگی‌ها

خط لوله با کلون کردن مخزن و نصب وابستگی‌هآ آغاز می‌شود: Gradle/Maven برای Android، CocoaPods یا SPM برای iOS. ذخیره‌سازی وابستگی‌ها در حافظه پنهان بین اجراها زمان نصب را از ۳–۵ دقیقه به چند ثانیه کاهش می‌دهد — این بهینه‌سازی توسط همه سرویس‌های CI مدرن پشتیبانی می‌شود.

۲. تحلیل استاتیک و لینتینگ

قبل از ساخت، کد توسط لینترها (ktlint، detekt برای Android، SwiftLint برای iOS) و تحلیلگرهای استاتیک (Android Lint، SonarQube) بررسی می‌شود. لینتینگ اشکالات بالقوه، نقض سبک کدنویسی و APIهای منسوخ را قبل از اجرای تست‌ها شناسایی می‌کند — اصل fail-fast در وقت تیم صرفه‌جویی می‌کند.

۳. ساخت پروژه

در مرحله ساخت، کل پروژه کامپایل شده و مصنوعات تولید می‌شوند: APK و AAB برای Android، IPA برای iOS. برای Android از وظایف Gradle (assembleDebug، bundleRelease) و برای iOS از xcodebuild یا xcrun استفاده می‌شود. ساخت در محیط ایزوله سرور CI انجام می‌شود که تکرارپذیری را تضمین می‌کند.

# مثال CI/CD Pipeline برای اندروید در GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

۴. تست خودکار

پس از ساخت، تست‌های واحد، تست‌های یکپارچه و تست‌های UI اجرا می‌شوند. JUnit و MockK برای تست‌های ماژولار، Espresso و Compose Test برای UI در Android، XCTest و XCUITest در iOS. نتایج در گزارش منتشر می‌شوند و در صورت شکست تست‌های بحرانی، خط لوله مسدود می‌شود.

۵. امضا و مبهم‌سازی

برای بیلدهای انتشار، امضا با گواهی دیجیتال (APK Signer برای Android، codesign برای iOS) و مبهم‌سازی کد انجام می‌شود. ProGuard یا R8 برای Android اندازه APK را ۱۵–۳۰پرصد کاهش می‌دهد. کلیدهای امضا در اسرار سرور CI ذخیره می‌شوند — هرگز در مخزن کامیت نمی‌شوند.

۶. تحویل و استقرار

مرحله نهایی خط لوله — انتشار مصنوعات: آپلود APK در تست داخلی Google Play Console، ارسال IPA به TestFlight یا انتشار در Firebase Distribution. Continuous Delivery به این معنی است که این مرحله نیاز به تأیید دستی دارد، در حالی که Continuous Deployment به صورت خودکار انجام می‌شود.

۷. اعلان‌ها و گزارش‌ها

پس از اتمام خط لوله، تیم اعلانی با نتایج دریافت می‌کند: موفقیت/شکست، زمان اجرا، لینک به مصنوعات. Slack، Telegram یا ایمیل — کانال‌های اعلان بر اساس نیاز تیم انتخاب می‌شوند. در صورت شکست مرحله، لینکی به لاگ خطای خاص در اعلان گنجانده می‌شود.

تفاوت CI با CD چیست

اصطلاحات CI و CD اغلب به عنوان یک مفهوم واحد CI/CD استفاده می‌شوند، اما تفاوت اساسی بین آنها وجود دارد. CI (Continuous Integration) مسئول بررسی کیفیت در هر ادغام کد است، در حالی که CD (Continuous Delivery) آمادگی این کد را برای انتشار تضمین می‌کند. درک تفاوت در طراحی خط لوله حیاتی است.

Continuous Integration — بررسی کیفیت

CI در هر push یا pull request اجرا می‌شود و شامل ساخت، تحلیل استاتیک و تست است. هدف CI — شناسایی مشکلات در اسرع وقت ممکن، زمانی که هزینه رفع آنها حداقل است. اگر CI عبور نکند — کد وارد شاخه اصلی نمی‌شود. میانگین زمان اجرای CI برای یک پروژه موبایل ۵–۱۵ دقیقه است.

Continuous Delivery — آمادگی برای انتشار

CD مراحل آماده‌سازی انتشار را به CI اضافه می‌کند: امضا، مبهم‌سازی، ایجاد یادداشت‌های انتشار، بررسی مجوزها، انتشار در مخزن برای تسترها. CD تضمین می‌کند که هر کامیت در شاخه اصلی می‌تواند با یک کلیک به تولید منتشر شود، اما خود انتشار نیاز به تأیید دستی دارد.

ابزارهای ساخت CI/CD Pipeline

اکوسیستم ابزارهای CI/CD برای توسعه اپلیکیشن‌های موبایل شامل سرویس‌های ابری، راه‌حل‌های خودمیزبانی و پلتفرم‌های تخصصی است. انتخاب ابزار به اندازه تیم، بودجه و الزامات امنیتی بستگی دارد. در زیر محبوب‌ترین گزینه‌ها ارائه شده است.

GitHub Actions

CI/CD داخلی در GitHub با محدودیت رایگان ۲۰۰۰ دقیقه در ماه برای مخازن عمومی. GitHub Actions به دلیل اکوسیستم عظیم action‌های آماده (marketplace)، سادگی پیکربندی از طریق YAML و یکپارچگی بی‌درز با مخزن GitHub محبوب است. محدودیت — عدم پشتیبانی از runnerهای Windows برای بیلدهای iOS در طرح رایگان.

GitLab CI/CD

راه‌حل خودمیزبانی و ابری با پیکربندی قدرتمند YAML. GitLab CI از jobهای موازی، ذخیره‌سازی حافظه پنهان، مصنوعات و محیط‌ها (environments) پشتیبانی می‌کند. در بخش enterprise به دلیل امکان استقرار در زیرساخت خود و کنترل کامل بر داده‌ها محبوب است.

Jenkins

سرور CI کلاسیک با کد منبع باز. Jenkins از طریق افزونه‌ها (بیش از ۱۸۰۰) پیکربندی می‌شود، از Declarative Pipeline در قالب Groovy پشتیبانی می‌کند و در هر محیطی کار می‌کند: Windows، macOS، Linux. نیاز به مدیریت اختصاصی دارد، اما حداکثر انعطاف‌پذیری پیکربندی را فراهم می‌کند.

CircleCI

سرویس CI ابری با تأکید بر سرعت و سادگی. CircleCI به طور خودکار وابستگی‌ها را ذخیره می‌کند، از تصاویر Docker برای بیلدهای ایزوله و یکپارچگی با macOS برای بیلدهای iOS پشتیبانی می‌کند. قیمت‌گذاری بر اساس تعداد اعتبار است — مناسب برای تیم‌هایی که به عملکرد اهمیت می‌دهند.

مثال پیکربندی CI/CD Pipeline

بیایید یک CI/CD Pipeline کامل برای اپلیکیشن iOS با استفاده از GitHub Actions و Fastlane را بررسی کنیم. Fastlane یک ابزار اتوماسیون برای پروژه‌های موبایل است که عملیات پیچیده ساخت، امضا و انتشار را به دستورات ساده انتزاع می‌کند.

# Fastfile — پیکربندی Fastlane برای iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "اجرای تست‌ها و lint"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "ساخت نسخه انتشار و بارگذاری در TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match گواهی‌ها و provisioning profiles را مدیریت می‌کند، build_app IPA را می‌سازد، pilot بیلد را در TestFlight آپلود می‌کند. دستور fastlane release تمام مراحل را به ترتیب اجرا می‌کند: گواهی‌ها را دریافت می‌کند، می‌سازد، امضا می‌کند، برای تسترهای بتا به App Store Connect آپلود می‌کند.

CI/CD Pipeline برای iOS با GitHub Actions

یکپارچگی Fastlane با GitHub Actions امکان اجرای خودکار خط لوله کامل را در pull request به شاخه main فراهم می‌کند. Self-hosted runner در macOS برای کامپایل کد iOS ضروری است — GitHub runnerهای macOS را در طرح رایگان ارائه نمی‌دهد.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

بهترین روش‌های CI/CD Pipeline

ساخت یک CI/CD Pipeline مؤثر نه تنها انتخاب ابزارها، بلکه پیروی از روش‌های اثبات‌شده را نیز می‌طلبد. بدون سازماندهی مناسب، خط لوله می‌تواند به یک تنگنا تبدیل شود که به جای تسریع، توسعه را کند می‌کند. در زیر — توصیه‌های کلیدی بر اساس تجربه تیم‌های موبایل بالغ ارائه شده است.

Fail fast

سریع‌ترین بررسی‌ها (لینتینگ، تست‌های واحد) ابتدا اجرا می‌شوند. اگر آنها شکست بخورند — خط لوله بدون اجرای تست‌های UI طولانی یا ساخت انتشار پایان می‌یابد. Fail fast در دقایق CI صرفه‌جویی می‌کند و بازخورد را به توسعه‌دهنده تسریع می‌بخشد. میانگین زمان تا اولین شکست نباید از ۲–۳ دقیقه تجاوز کند.

ذخیره‌سازی وابستگی‌ها در حافظه پنهان

کش Gradle، کش CocoaPods و کش SPM باید بین اجراها بازیابی شوند. GitHub Actions از ذخیره‌سازی از طریق actions/cache، GitLab CI — از طریق کلمه کلیدی cache پشتیبانی می‌کند. بدون ذخیره‌سازی، هر ساخت همه وابستگی‌ها را دوباره دانلود می‌کند — این ۳–۱۰ دقیقه به زمان خط لوله اضافه می‌کند.

اجرای موازی

مراحل مستقل (لینتر برای Android و iOS، تست‌های واحد ماژول‌های مختلف) به عنوان jobهای موازی اجرا می‌شوند. موازی‌سازی زمان کل خط لوله را از ۲۰–۳۰ دقیقه به ۵–۱۰ دقیقه کاهش می‌دهد. بیشتر سرویس‌های CI jobهای موازی را جداگانه حساب می‌کنند — هنگام انتخاب طرح تعرفه این را در نظر بگیرید.

ایزوله‌سازی محیط

هر اجرای خط لوله در یک محیط تمیز انجام می‌شود: کانتینر Docker، ماشین مجازی یا runner موقت. ایزوله‌سازی از تأثیر بیلدهای قبلی بر بیلد جاری جلوگیری می‌کند. از استفاده از runnerهای مشترک بین پروژه‌ها خودداری کنید — آلودگی محیط بین پروژه‌ای منجر به خرابی‌های غیرقطعی می‌شود.

امنیت اسرار

کلیدهای API، گواهی‌های امضا و توکن‌های دسترسی به فروشگاه‌های اپلیکیشن در ذخیره‌گاه رمزگذاری‌شده سرور CI ذخیره می‌شوند. هرگز اسرار را در لاگ‌ها، مصنوعات یا متغیرهای محیطی بدون پیشوند SECRET_ قرار ندهید. از ابزارهایی مانند Fastlane match برای مدیریت گواهی‌های iOS استفاده کنید.