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 نے 2010 کی دہائی میں سب سے پہلے CD اپنایا — آج یہ پروڈکٹ ٹیموں کے لیے معیار ہے۔

CD کی کاروباری قدر

تیز فیچر ڈیلیوری ایک مسابقتی فائدہ ہے۔ اگر کوئی حریف دنوں میں نئی فعالیت جاری کرتا ہے جبکہ آپ کو مہینے لگتے ہیں، مارکیٹ حریف کا انتخاب کرتی ہے۔ DORA میٹرکس ظاہر کرتی ہیں: ایلیٹ ٹیمیں (CD کے ساتھ) 1 گھنٹے سے کم ڈپلائے ٹائم رکھتی ہیں، کم ٹیمیں (CD کے بغیر) — 1 ہفتے سے 1 مہینے تک۔ CD خطرے کو بھی یکسر کم کرتا ہے: چھوٹی تبدیلیاں بڑی سہ ماہی ریلیز کے مقابلے میں چیزیں توڑنا زیادہ مشکل ہوتی ہیں۔

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

اصطلاحات CI، CD اور Continuous Deployment اکثر الجھ جاتی ہیں، لیکن ان کے درمیان ایک واضح حد ہے۔ فرق کو سمجھنا پائپ لائن کو صحیح طریقے سے ڈیزائن کرنے اور آٹومیشن کی سطح کا انتخاب کرنے میں مدد کرتا ہے جو ٹیم کی پختگی اور کاروباری ضروریات سے میل کھاتا ہو۔

Continuous Integration

CI وہ بنیاد ہے جس پر CD تعمیر کیا گیا ہے۔ CI اس بات کو یقینی بناتا ہے کہ ہر کمٹ بلڈ اور ٹیسٹ سے گزرے۔ 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 میں ایسی خصوصیات ہیں جو اسے ویب اور بیک اینڈ پائپ لائنوں سے ممتاز کرتی ہیں۔ موبائل ریلیز ایپ اسٹورز (App Store Review، Google Play Review) سے گزرتی ہیں، جو وقت اور عمل کی رکاوٹ شامل کرتا ہے۔ 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)، میٹا ڈیٹا (نام، وضاحت، کلیدی الفاظ) کی توثیق، پرائیویٹ APIs کی عدم موجودگی کی جانچ ضروری ہے۔ تکنیکی توثیق altool --validate-app کے ذریعے App Store Connect پر اپ لوڈ کیے بغیر کی جاتی ہے، جو فوری فیڈ بیک فراہم کرتی ہے۔

# Fastfile — iOS اور Android کے لیے مکمل CD پائپ لائن
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 پر اپ لوڈ کرتا ہے۔ Android کے لیے deliver_to_internal لین Gradle کے ذریعے Release AAB بناتی ہے اور اسے Google Play Console کے اندرونی ٹریک پر اپ لوڈ کرتی ہے۔ دونوں پائپ لائنیں ٹیسٹ پاس کرنے کے بعد CI سے چلتی ہیں۔

CD پائپ لائن کے اجزاء

CD پائپ لائن ترتیب وار مراحل پر مشتمل ہے، ہر ایک اعتماد بڑھاتا ہے کہ ریلیز صارفین کے لیے تیار ہے۔ مراحل تکنیکی (بلڈ، دستخط) اور مصنوعاتی (میٹا ڈیٹا، اسکرین شاٹس، وضاحت کی تصدیق) میں تقسیم ہیں۔ کسی بھی مرحلے کو چھوڑنے سے ایپ اسٹور کے ذریعے ریلیز مسترد ہونے کا خطرہ بڑھ جاتا ہے۔

ورژن مینجمنٹ

CD کا ایک اہم جز خودکار ورژن مینجمنٹ ہے۔ ورژن میں اضافہ (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 بلڈ کے ساتھ وضاحتیں، اسکرین شاٹس اور آئیکن اپ لوڈ کرنے کو خودکار کرتے ہیں۔

گیٹ چیکس

جائزے کے لیے جمع کروانے سے پہلے، پائپ لائن گیٹ چیکس کرتی ہے: بلڈ سائز چیک (APK > 200 MB Google Play کے ذریعے مسترد)، تمام لوکلائزیشنز کی موجودگی، ریلیز بلڈ میں ڈیبگ علامات کی عدم موجودگی، کریش لاگز کو ڈی کوڈ کرنے کے لیے ProGuard میپنگ فائل چیک۔ اگر کوئی چیک ناکام ہوتا ہے — پائپ لائن ریلیز کو روک دیتی ہے۔

CD کے لیے خودکار جانچ

CD میں اعتماد کی سطح خودکار ٹیسٹوں کے معیار کے متناسب ہے۔ اگر ٹیسٹ regression نہیں پکڑتے — ریلیز پروڈکشن کو توڑ سکتی ہے اور ٹیم CD میں اعتماد کھو دیتی ہے۔ موبائل CD کے لیے پلیٹ فارم کی خصوصیات کے مطابق تین سطحی ٹیسٹ پیرامڈ کی ضرورت ہے۔

یونٹ ٹیسٹ

یونٹ ٹیسٹ کاروباری منطق کو علیحدہ طور پر تصدیق کرتے ہیں۔ اہم ماڈیولز (تصدیق، ادائیگی، نیٹ ورکنگ) کے لیے کوڈ کوریج کم از کم 70% ہونی چاہیے۔ CI ہر push پر یونٹ ٹیسٹ چلاتا ہے، اور اگر وہ ناکام ہوتے ہیں — CD پائپ لائن ٹھیک ہونے تک مسدود ہو جاتی ہے۔

انٹیگریشن ٹیسٹ

یہ اجزاء کے تعامل کی تصدیق کرتے ہیں: حقیقی API (یا mock سرور) کے ساتھ نیٹ ورک پرت، ڈیٹا بیس، فائل سسٹم۔ Android کے لیے Room DAO ٹیسٹ، iOS کے لیے Core Data ٹیسٹ انٹیگریشن ٹیسٹ کی مثالیں ہیں۔ یہ یونٹ ٹیسٹ (1–5 منٹ) سے سست ہیں اور CD مرحلے میں عمل میں لائے جاتے ہیں، ہر commit پر CI میں نہیں۔

UI اور اسکرین شاٹ ٹیسٹ

اسکرین شاٹ ٹیسٹ (snapshot testing) ایپ اسکرینوں کا موازنہ ریفرنس امیجز سے کرتے ہیں۔ اگر کوڈ تبدیلی نے UI تبدیل کیا — ٹیسٹ ناکام ہو جاتا ہے اور ڈویلپر چیک کرتا ہے کہ تبدیلی متوقع ہے یا نہیں۔ Android Roborazzi اور Paparazzi کو سپورٹ کرتا ہے، iOS — Point-Free کی SnapshotTesting کو۔ اسکرین شاٹ ٹیسٹ CD پائپ لائن کے حصے کے طور پر ریلیز سے پہلے عمل میں لائے جاتے ہیں۔

Continuous Delivery کے بہترین طرز عمل

Continuous Delivery کو نافذ کرنے کے لیے نہ صرف ٹولز بلکہ ٹیم کی ثقافت میں تبدیلی کی بھی ضرورت ہے۔ نیچے دیے گئے طرز عمل Google، Spotify اور Uber کی موبائل ٹیموں کے سالوں کے تجربے پر مبنی ہیں اور کسی بھی سائز کے پروجیکٹ کے لیے ڈھالے گئے ہیں۔

Feature Flags

نئے فیچر کا کوڈ پروڈکشن میں بھیجا جاتا ہے لیکن ایک جھنڈے کے پیچھے چھپا ہوتا ہے۔ Feature flags فیچر کے صارفین کے لیے تیار ہونے سے پہلے کوڈ ڈپلائے کرنے اور مسئلہ ہونے پر فوری طور پر اسے غیر فعال کرنے کی اجازت دیتے ہیں۔ لائبریریاں: LaunchDarkly، Firebase Remote Config، Unleash۔ Feature flags موبائل پروجیکٹس میں CD کے لیے ایک لازمی شرط ہے۔

اسٹیجنگ ماحول

پروڈکشن میں بھیجنے سے پہلے، بلڈ اسٹیجنگ پر ڈپلائے کیا جاتا ہے — پروڈکشن جیسا ماحول لیکن ٹیسٹ ڈیٹا کے ساتھ۔ QA انجینئرز TestFlight یا Internal Testing ٹریک کے ذریعے انسٹال کردہ اسٹیجنگ بلڈ پر فیچر کی تصدیق کرتے ہیں۔ اگر اسٹیجنگ پاس ہو جاتا ہے — بلڈ کو اسٹور کے جائزے کے لیے جمع کروانے کی منظوری مل جاتی ہے۔

ریلیز نوٹس اور چینج لاگ

CD کمٹ میسیجز کی بنیاد پر خود بخود ریلیز نوٹس تیار کرتا ہے۔ Conventional Commits (feat:, fix:, chore:) اور semantic versioning فارمیٹ میں Git ٹیگز تبدیلی کی تاریخ کو پارس کرنے کی اجازت دیتے ہیں۔ Fastlane changelog_from_git_commits آخری دو ٹیگز کے درمیان تبدیلیاں جمع کرتا ہے اور انہیں ایپ اسٹور کے لیے فارمیٹ کرتا ہے۔

ریلیز کے بعد کی نگرانی

CD اشاعت کے ساتھ ختم نہیں ہوتا — ریلیز کے بعد، نگرانی شروع ہوتی ہے: کریش کی شرح، Android کے لیے ANR کی شرح، لانچ کا وقت، ادائیگی کی ناکامی کی شرح۔ اگر میٹرکس عام حدوں سے باہر جاتے ہیں — CD پائپ لائن کو خود بخود ریلیز واپس لینی چاہیے یا ٹیم کو مطلع کرنا چاہیے۔ ٹولز: Firebase Crashlytics، Sentry، New Relic۔

// CD کے لیے Firebase Remote Config کے ساتھ Feature Flag کی مثال
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()
}