Continuous Delivery (CD): این چیست، چگونه با Continuous Deployment متفاوت است

Continuous Delivery چیست

Continuous Delivery (CD) — افزایشی از Continuous Integration است که اتوماسیون تمام مراحل آماده‌سازی رلیز را اضافه می‌کند: ساخت نسخه رلیزی، امضای دیجیتال، ایهام‌سازی، بررسی فراوردات فروشگاه کاربردی و استقرار در محیط staging. این مقطل توسط Jez Humble و David Farley در کتاب «Continuous Delivery» (2010) معرفی شد.

تکامل تحویل نرم‌افزار

قبل از اجرای CD، رلیزها یک رویداد بودند: تیم در یک اتاق جمع می‌شد، چک‌لیستی از 20 مورد را انجام می‌داد، اسکریپت‌ها را دستی اجرا می‌کرد و امیدوار بود که چیزی نمی‌شکند. Continuous Delivery رلیز را از یک رویداد به یک فرآیند تبدیل می‌کند: تغییر کوچک در کد می‌تواند ظرف دقایقی به دست کاربران برسد، نه هفته‌ها. Amazon، Netflix و Etsy اولین کسانی بودند که CD را در دهه 2010 اجرا کردند — امروزه این یک استاندارد برای تیم‌های محصولی است.

ارزش تجاری CD

تحویل سریع ویژگی‌ها یک مزیت رقابتی است. اگر رقیب یک قابلیت جدید را ظرف روزها منتشر کند و شما ظرف ماه‌ها، بازار رقیب را انتخاب می‌کند. متریک‌های DORA نشان می‌دهند: تیم‌های elite (با CD) زمان استقرار کمتر از 1 ساعت دارند، تیم‌های low (بدون CD) — از 1 هفته تا 1 ماه. CD همچنین ریسک را به شدت کاهش می‌دهد: تغییرات کوچک شکستنش از یک رلیز بزرگ سه ماهه سخت‌تر است.

CD vs CI vs Continuous Deployment

اصطلاحات CI، CD و Continuous Deployment اغلب اشتباه گرفته می‌شوند، اما مرز واضحی بین آن‌ها وجود دارد. درک تفاوت‌ها به طراحی درست پایپلاین و انتخاب سطح اتوماسیون مناسب با بلوغ تیم و نیازهای تجاری کمک می‌کند.

Continuous Integration

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

Continuous Delivery

CD به CI مراحل ساخت نسخه رلیزی، بررسی فراوردات، امضا و استقرار در محیط staging یا فروشگاه کاربردی برای آزمایشات بتا را اضافه می‌کند. تفاوت کلیدی — تصمیم درباره انتشار در تولید را یک انسان (مدیر، مالک محصول) می‌گیرد. CD رلیز را «یک کلیکی» — ساده و ایمن می‌کند.

Continuous Deployment

Continuous Deployment اتوماسیون کامل است: هر تغییری که از تمام مراحل پایپلاین CD گذر کند، بدون تایید دستی به طور خودکار به تولید ارسال می‌شود. Continuous Deployment برای محصولات SaaS و خدمات وب قابل استفاده است، اما به دلیل سیاست‌های فروشگاه‌های کاربردی به ندرت در توسعه موبایل استفاده می‌شود.

Continuous Delivery برای برنامه‌های موبایل

CD برای برنامه‌های موبایل ویژگی‌هایی دارد که آن را از پایپلاین‌های وب و بکاند متمایز می‌کند. رلیزهای موبایل از فروشگاه‌های کاربردی عبور می‌کنند که مانعی زمانی و رویه‌ای ایجاد می‌کند. CD هر چیزی را که می‌توان قبل از ارسال برای بررسی اتوماتیزه کرد اتوماتیزه می‌کند.

آماده‌سازی برای انتشار در Google Play

پایپلاین Android CD شامل است: ساخت AAB (Android App Bundle)، امضای دیجیتال با کلید رلیزی، ایهام‌سازی از طریق R8/ProGuard، بررسی اندازه APK و کلاس‌های multidex، تولید یادداشت‌های رلیز. استفاده از Gradle product flavors (free/paid, dev/staging/prod) امکان مدیریت چندین پیکربندی را از یک پایپلاین فراهم می‌کند.

آماده‌سازی برای انتشار در App Store

iOS CD نیازمند امضای دیجیتال با گواهینامه‌ها از طریق Fastlane match، بررسی مطابقت آیکون‌ها (نیاز App Store — 1024×1024 px)، اعتبارسنجی فراوردات (نام، توضیحات، کلمات کلیدی)، بررسی عدم وجود API‌های خصوصی است. Technical validation از طریق altool --validate-app بدون بارگذاری در App Store Connect انجام می‌شود.

# Fastfile — پایپلاین کامل CD برای iOS و Android
platform :ios do
  desc "iOS CD — آماده‌سازی رلیز و بارگذاری در TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "Android CD — ساخت AAB و بارگذاری در Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight نمایشگرفتاری‌ها را جمع و match گواهینامه می‌گیرد، IPA را ساخته و به TestFlight بارگذاری می‌کند. Lane-i deliver_to_internal برای Android از طریق Gradle Release AAB ساخته و آن را به ترک داخلی Google Play Console بارگذاری می‌کند. هر دو پایپلاین پس از گذشتن آزمایش‌ها از CI اجرا می‌شوند.

اجزای CD‑pipeline

CD pipeline از مراحل پیاپی تشکیل شده است که هر کدام اطمینان از آمادگی رلیز برای کاربران را افزایش می‌دهد. مراحل به فنی (ساخت، امضا) و محصولی (بررسی فراوردات، نمایشگرفتاری‌ها، توضیحات) تقسیم می‌شوند. ناویزی هر مرحله ریسک رد رلیز توسط فروشگاه کاربردی را افزایش می‌دهد.

مدیریت نسخه

یک جزء حیاتی CD — مدیریت خودکار نسخه. Version bump (برای Android: versionCode و versionName، برای iOS: CFBundleVersion و CFBundleShortVersionString) بر اساس تگ‌های Git یا نسخه قبلی در فروشگاه انجام می‌شود. Fastlane increment_version_number و دستورات Gradle (versionCode auto-increment) این مرحله را اتوماتیزه می‌کنند.

فراوردات فروشگاه

Google Play Console و App Store Connect نیاز دارند: توضیح کاربردی، کلمات کلیدی، دسته‌بندی، رتبه، پیوندهای سیاست حفظ حریم خصوصی. CD شامل بررسی وجود و صحت فراوردات است. Fastlane deliver و supply بارگذاری توضیحات، نمایشگرفتاری‌ها و آیکون‌ها را همراه با ساخت اتوماتیزه می‌کنند.

بازرسی‌های Gates

قبل از ارسال برای بررسی، pipeline بازرسی‌های دروازه‌ای انجام می‌دهد: بررسی اندازه ساخت (APK > 200 MB توسط Google Play رد می‌شود)، وجود تمام زبان‌ها، عدم وجود علائم تصحیح در نسخه رلیزی، بررسی فایل ProGuard mapping. اگر حتی یک بازرسی موفق نباشد — pipeline رلیز را بلوک می‌کند.

آزمایش خودکار برای CD

سطح اعتماد به CD مستقیما با کیفیت آزمایش‌های خودکار متناسب است. اگر آزمایش‌ها بازگشت‌ها را نگیرند، رلیز می‌تواند تولید را خراب کند و تیم اعتماد خود را به CD از دست می‌دهد. CD موبایل نیازمند هرم آزمایش سه سطحی است که با ویژگی‌های سطح سازگار شده است.

آزمایش‌های واحد

آزمایش‌های واحد منطق کسب و کار را به صورت انزوا بررسی می‌کنند. پوشش کد برای ماژول‌های حساس (حرازت، پرداخت، کار با شبکه) باید حداقل 70% باشد. CI آزمایش‌های واحد را در هر push اجرا می‌کند و اگر ناکام باشند، پایپلاین CD تا رفع مشکل بلوک می‌شود.

آزمایش‌های یکپارچگی

تعامل میان جزئها را بررسی می‌کنند: لایه شبکه با API واقعی (or سرور مقلد)، پایگاه داده، فایل سیستم. آزمایش‌های Room DAO برای Android، آزمایش‌های Core Data برای iOS — نمونه آزمایش‌های یکپارچگی. آنها کندتر از آزمایش‌های واحد هستند (1–5 دقیقه).

آزمایش‌های UI و نمایشگرفتاری

آزمایش‌های نمایشگرفتاری (snapshot testing) صفحات کاربردی را با تصاویر مرجع مقایسه می‌کنند. اگر تغییر کد UI را تغییر دهد، آزمایش مردود می‌شود. Android Roborazzi و Paparazzi را ‌دستگیری می‌کند، iOS SnapshotTesting از Point-Free را دارد. این آزمایش‌ها قبل از رلیز انجام می‌شوند.

رویکردهای بهترین Continuous Delivery

اجرای Continuous Delivery نه تنها به ابزارها، بلکه به تغییر فرهنگ تیم نیز نیاز دارد. رویکردهای زیر بر اساس تجربه چندین ساله تیم‌های موبایل Google، Spotify و Uber است.

Feature flags

کد ویژگی جدید به تولید می‌رود اما پشت یک پرچم پنهان است. Feature flags امکان ودره کد را قبل از آمادگی ویژگی فراهم می‌کند. کتابخانه‌ها: LaunchDarkly، Firebase Remote Config، Unleash. Feature flags شرط ضروری CD در پروژه‌های موبایل است.

محیط Staging

قبل از ارسال به تولید، ساخت در staging — محیطی مانند تولید اما با داده‌های آزمایشی — منتشر می‌شود. مهندسان QA ویژگی را در ساخت staging نصب شده از طریق TestFlight یا Internal Testing track بررسی می‌کنند. اگر staging تأیید شود، ساخت برای ارسال به بررسی در فروشگاه تأیید می‌شود.

یادداشت‌های رلیز و changelog

CD به طور خودکار یادداشت‌های رلیز را بر اساس commit messages تولید می‌کند. Conventional Commits (feat:, fix:, chore:) و تگ‌های Git در فرمات semantic versioning امکان تجزیه و تحلیل تاریخچه تغییرات را فراهم می‌کنند. Fastlane changelog_from_git_commits تغییرات بین دو تگ آخر را جمع و برای فروشگاه کاربردی فرمات می‌کند.

نظارت پس از رلیز

CD با انتشار خاتمه نمی‌یابد. پس از رلیز نظارت آغاز می‌شود: crash rate، ANR rate برای Android، زمان شروع، تعداد شکست‌های پرداخت. اگر متریک‌ها از محدوده خارج شوند، CD pipeline باید رلیز را خودکار برگرداند. ابزارها: Firebase Crashlytics، Sentry، New Relic.

// مثال Feature Flag با Firebase Remote Config برای CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// استفاده در کد
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}