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 सुनिश्चित करता है कि हर 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 में ऐसी विशेषताएं हैं जो इसे वेब और बैकएंड पाइपलाइनों से अलग करती हैं। मोबाइल रिलीज़ ऐप स्टोर (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 में विश्वास का स्तर स्वचालित परीक्षणों की गुणवत्ता के समानुपाती होता है। यदि परीक्षण प्रतिगमन नहीं पकड़ते — रिलीज़ प्रोडक्शन तोड़ सकती है, और टीम CD में विश्वास खो देती है। मोबाइल CD के लिए प्लेटफ़ॉर्म की विशिष्टताओं के अनुकूल तीन-स्तरीय परीक्षण पिरामिड की आवश्यकता होती है।

यूनिट टेस्ट

यूनिट टेस्ट व्यावसायिक तर्क को अलगाव में सत्यापित करते हैं। महत्वपूर्ण मॉड्यूल (प्रमाणीकरण, भुगतान, नेटवर्किंग) के लिए कोड कवरेज कम से कम 70% होना चाहिए। CI हर push पर यूनिट टेस्ट चलाता है, और यदि वे विफल होते हैं — CD पाइपलाइन ठीक होने तक ब्लॉक हो जाती है।

इंटीग्रेशन टेस्ट

वे घटक अंतःक्रिया की जांच करते हैं: वास्तविक API (या मॉक सर्वर) के साथ नेटवर्क लेयर, डेटाबेस, फ़ाइल सिस्टम। 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। मोबाइल प्रोजेक्ट्स में CD के लिए Feature flags एक अनिवार्य आवश्यकता है।

स्टेजिंग वातावरण

प्रोडक्शन में भेजने से पहले, बिल्ड को स्टेजिंग पर डिप्लॉय किया जाता है — प्रोडक्शन के समान लेकिन टेस्ट डेटा वाला वातावरण। QA इंजीनियर TestFlight या Internal Testing ट्रैक के माध्यम से स्थापित स्टेजिंग बिल्ड पर फीचर की जांच करते हैं। यदि स्टेजिंग पास हो जाता है — बिल्ड को समीक्षा के लिए स्टोर में सबमिट करने की मंजूरी मिल जाती है।

रिलीज़ नोट्स और चेंजलॉग

CD commit messages के आधार पर स्वचालित रूप से रिलीज़ नोट्स जनरेट करता है। 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()
}