Continuous Delivery (CD): ما هو، الفرق عن Continuous Deployment

ما هو Continuous Delivery

Continuous Delivery (CD) هي امتداد لـ Continuous Integration تضيف أتمتة لجميع مراحل تحضير الإصدار: بناء النسخة الإصدارية، التوقيع بالشهادات، التعتيم، التحقق من البيانات الوصفية لمتجر التطبيقات والنشر في بيئة الاختبار. تم تقديم المصطلح من قبل Jez Humble وDavid Farley في كتاب «Continuous Delivery» (2010)، حيث قاما بصياغة الممارسة التي تمكن الفرق من جعل الإصدارات قابلة للتنبؤ ومنخفضة المخاطر.

تطور تسليم البرمجيات

قبل اعتماد CD، كانت الإصدارات حدثًا: كان الفريق يجتمع في غرفة، وينفذ قائمة مراجعة من 20 نقطة، ويشغل البرامج النصية يدويًا، ويأمل ألا ينكسر شيء. Continuous Delivery يحول الإصدار من حدث إلى عملية: يمكن شحن تغيير صغير في الكود إلى المستخدمين في دقائق، وليس أسابيع. Amazon وNetflix وEtsy كانت أول من اعتمد CD في العقد 2010 — واليوم هو المعيار لفرق المنتجات.

القيمة التجارية لـ CD

التسليم السريع للميزات هو ميزة تنافسية. إذا كان المنافس يصدر وظائف جديدة في أيام بينما تستغرق أنت شهورًا، يختار السوق المنافس. مقاييس DORA تظهر: فرق النخبة (مع CD) لديها وقت نشر أقل من ساعة واحدة، الفرق المنخفضة (بدون CD) — من أسبوع إلى شهر. CD أيضًا يقلل المخاطر بشكل جذري: التغييرات الصغيرة أصعب في كسر الأشياء من إصدار كبير ربع سنوي.

CD مقابل CI مقابل Continuous Deployment

المصطلحات CI وCD وContinuous Deployment غالبًا ما يتم الخلط بينها، ولكن هناك حدود واضحة بينها. فهم الاختلافات يساعد في تصميم خط الأنابيب بشكل صحيح واختيار مستوى الأتمتة الذي يتناسب مع نضج الفريق والمتطلبات التجارية.

Continuous Integration

CI هو الأساس الذي يُبنى عليه CD. يضمن CI أن كل commit يمر عبر البناء والاختبار. بدون CI، CD مستحيل: إذا لم يتم التحقق من الكود، لا يمكن إصداره. CI يتحقق من الصحة، CD يتحقق من الجاهزية للاستخدام التجاري.

Continuous Delivery

CD يضيف إلى CI مراحل بناء النسخة الإصدارية، التحقق من البيانات الوصفية، التوقيع والنشر في بيئة الاختبار أو متجر التطبيقات للاختبار التجريبي. الفرق الرئيسي — قرار الإصدار إلى الإنتاج يتخذه شخص (مدير، مالك المنتج). CD يجعل الإصدار «على بعد نقرة واحدة» — بسيط وآمن.

Continuous Deployment

Continuous Deployment هو أتمتة كاملة: كل تغيير يمر عبر جميع مراحل خط أنابيب CD يتم إرساله تلقائيًا إلى الإنتاج بدون موافقة يدوية. Continuous Deployment قابل للتطبيق لمنتجات SaaS والخدمات الويب، لكن نادرًا ما يستخدم في تطوير التطبيقات المحمولة بسبب سياسات متاجر التطبيقات (App Store Review، Google Play Review تتطلب إرسال يدوي).

Continuous Delivery للتطبيقات المحمولة

CD للتطبيقات المحمولة له ميزات تميزه عن خطوط أنابيب الويب وال backend. الإصدارات المحمولة تمر عبر متاجر التطبيقات (App Store Review، Google Play Review)، مما يضيف حاجزًا زمنيًا وإجرائيًا. CD يؤتمت كل ما يمكن أتمتته قبل الإرسال للمراجعة لتعظيم فرصة اجتياز التحقق من المحاولة الأولى.

التحضير للنشر في Google Play

خط أنابيب CD لنظام Android يشمل: بناء AAB (Android App Bundle)، التوقيع بمفتاح إصدار، التعتيم عبر R8/ProGuard، التحقق من حجم APK وفئات multidex، إنشاء ملاحظات الإصدار. استخدام product flavors في Gradle (free/paid، dev/staging/prod) يسمح بإدارة تكوينات متعددة من خط أنابيب واحد.

التحضير للنشر في App Store

CD لنظام iOS يتطلب التوقيع بشهادات عبر Fastlane match، التحقق من مطابقة الأيقونات (متطلب App Store — 1024×1024 بكسل)، التحقق من صحة البيانات الوصفية (الاسم، الوصف، الكلمات المفتاحية)، التحقق من عدم وجود APIs خاصة. يتم التحقق الفني عبر 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. المسار deliver_to_internal لنظام Android يبني Release AAB عبر Gradle ويرفعه إلى المسار الداخلي لـ Google Play Console. كلا خطي الأنابيب يعملان من CI بعد اجتياز الاختبارات.

مكونات خط أنابيب CD

خط أنابيب CD يتكون من مراحل متتالية، كل منها يضيف ثقة بأن الإصدار جاهز للمستخدمين. تنقسم المراحل إلى تقنية (بناء، توقيع) ومنتجة (بيانات وصفية، لقطات شاشة، التحقق من الوصف). تخطي أي مرحلة يزيد من خطر رفض الإصدار من قبل متجر التطبيقات.

إدارة الإصدارات

مكون حاسم في CD هو إدارة الإصدارات التلقائية. زيادة الإصدار (versionCode وversionName لنظام Android، CFBundleVersion وCFBundleShortVersionString لنظام iOS) يتم بناءً على علامات Git أو الإصدار السابق في المتجر. Fastlane increment_version_number وأوامر Gradle (versionCode auto-increment) تؤتمت هذه الخطوة.

البيانات الوصفية للمتجر

Google Play Console وApp Store Connect يتطلبان: وصف التطبيق، الكلمات المفتاحية، الفئة، التقييم، روابط سياسة الخصوصية. CD يشمل التحقق من وجود وصحة البيانات الوصفية. Fastlane deliver وsupply يؤتمتان رفع الأوصاف ولقطات الشاشة والأيقونات مع البناء.

فحوصات البوابة

قبل الإرسال للمراجعة، يقوم خط الأنابيب بفحوصات البوابة: فحص حجم البناء (APK > 200 ميغابايت مرفوض من Google Play)، وجود جميع التعريب، عدم وجود رموز تصحيح في البناء الإصدار، فحص ملف mapping ProGuard لفك تشفير سجلات الأعطال. إذا فشل أي فحص — خط الأنابيب يحظر الإصدار.

الاختبار الآلي لـ CD

مستوى الثقة في CD يتناسب طرديًا مع جودة الاختبارات الآلية. إذا لم تكتشف الاختبارات الانحدار — يمكن للإصدار كسر الإنتاج، ويفقد الفريق الثقة في CD. CD للتطبيقات المحمولة يتطلب هرم اختبار ثلاثي المستويات مكيف لخصوصية المنصة.

اختبارات الوحدة

اختبارات الوحدة تتحقق من منطق الأعمال بشكل معزول. تغطية الكود يجب أن لا تقل عن 70% للوحدات الحرجة (المصادقة، المدفوعات، الشبكات). CI يشغل اختبارات الوحدة عند كل push، وإذا فشلت — خط أنابيب CD يُحظر حتى الإصلاح.

اختبارات التكامل

تتحقق من تفاعل المكونات: طبقة الشبكة مع API حقيقي (أو خادم mock)، قاعدة البيانات، نظام الملفات. اختبارات Room DAO لنظام Android، اختبارات Core Data لنظام iOS هي أمثلة على اختبارات التكامل. هي أبطأ من اختبارات الوحدة (1–5 دقائق) وتُنفذ في مرحلة CD، وليس CI عند كل commit.

اختبارات واجهة المستخدم ولقطات الشاشة

اختبارات لقطات الشاشة (snapshot testing) تقارن شاشات التطبيق بالصور المرجعية. إذا غيّر تغيير الكود واجهة المستخدم — يفشل الاختبار، ويتحقق المطور مما إذا كان التغيير متوقعًا. Android يدعم Roborazzi وPaparazzi، iOS — SnapshotTesting من Point-Free. اختبارات لقطات الشاشة تُنفذ قبل الإصدار كجزء من خط أنابيب CD.

أفضل ممارسات Continuous Delivery

تنفيذ Continuous Delivery يتطلب ليس فقط أدوات بل أيضًا تغيير في ثقافة الفريق. الممارسات أدناه مبنية على سنوات من الخبرة لفرق التطبيقات المحمولة من Google وSpotify وUber ومكيفة لمشاريع من أي حجم.

Feature Flags

كود الميزة الجديدة يُشحن إلى الإنتاج لكنه مخفي خلف علامة. Feature flags تسمح بنشر الكود قبل أن تكون الميزة جاهزة للمستخدمين وإيقافها فورًا في حالة المشاكل. المكتبات: LaunchDarkly، Firebase Remote Config، Unleash. Feature flags هي شرط إلزامي لـ CD في المشاريع المحمولة.

بيئة الاختبار

قبل الشحن إلى الإنتاج، يُنشر البناء في staging — بيئة مطابقة للإنتاج لكن ببيانات اختبار. مهندسو QA يتحققون من الميزة على بناء staging مثبت عبر TestFlight أو مسار Internal Testing. إذا اجتاز staging — يحصل البناء على الموافقة للإرسال للمراجعة في المتجر.

ملاحظات الإصدار وسجل التغييرات

CD يولّد تلقائيًا ملاحظات الإصدار بناءً على رسائل commit. Conventional Commits (feat:، fix:، chore:) وعلامات Git بتنسيق semantic versioning تسمح بتحليل تاريخ التغييرات. Fastlane changelog_from_git_commits يجمع التغييرات بين آخر علامتين ويُنسقها لمتجر التطبيقات.

المراقبة بعد الإصدار

CD لا ينتهي بالنشر — بعد الإصدار، تبدأ المراقبة: معدل الأعطال، معدل ANR لنظام Android، وقت بدء التشغيل، معدل فشل المدفوعات. إذا تجاوزت المقاييس الحدود الطبيعية — يجب على خط أنابيب CD التراجع تلقائيًا عن الإصدار أو إخطار الفريق. الأدوات: 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()
}