Continuous Delivery (CD): bu nima va Continuous Deploymentdan nimasi bilan farq qiladi

Continuous Delivery nima

Continuous Delivery (CD) — bu Continuous Integrationning kengaytmasi bo'lib, relizni tayyorlashning barcha bosqichlarini avtomatlashtiradi: reliz buildini yig'ish, sertifikatlar bilan imzolash, obfuskatsiya, ilovalar do'konining metadatalarini tekshirish va stagingga deploy qilish. Bu atama Jez Humble va David Farley tomonidan „Continuous Delivery“ (2010) kitobida kiritilgan bo'lib, unda jamoalarga relizlarni bashorat qilinadigan va past xavfli qilish imkonini beradigan amaliyotni rasmiylashtirishgan.

Dasturiy ta'minotni yetkazib berish evolyutsiyasi

CD joriy etilishidan oldin relizlar voqea edi: jamoa xonada to'planar, 20 banddan iborat tekshiruv ro'yxatini bajarar, skriptlarni qo'lda ishga tushirar va hech narsa buzilmasligiga umid qilardi. Continuous Delivery relizni voqeadan jarayonga aylantiradi: kichik kod o'zgarishi foydalanuvchilarga haftalarda emas, daqiqalarda yetkazilishi mumkin. Amazon, Netflix va Etsy CDni birinchi bo'lib 2010-yillarda joriy etishdi — bugungi kunda bu mahsulot jamoalari uchun standartdir.

CDning biznes qiymati

Funksiyalarni tez yetkazib berish — raqobat ustunligi. Agar raqobatchi yangi funksiyani kunlarda chiqarsa, siz esa oylarda — bozor raqobatchini tanlaydi. DORA metrikalari ko'rsatadi: elite jamoalar (CD bilan) chiqarish vaqtini 1 soatdan kam qiladi, low jamoalar (CDsiz) — 1 haftadan 1 oygacha. CD xavfni ham tubdan kamaytiradi: kichik o'zgarishlarni buzish katta relizdan ko'ra qiyinroq.

CD vs CI vs Continuous Deployment

CI, CD va Continuous Deployment atamalarini ko'pincha chalkashtirishadi, lekin ular o'rtasida aniq chegara bor. Farqlarni tushunish pipeline to'g'ri loyihalashga va jamoaning yetukligi hamda biznes talablariga mos keladigan avtomatlashtirish darajasini tanlashga yordam beradi.

Continuous Integration

CI — bu CD quriladigan poydevordir. CI har bir commitning yig'ish va testlardan o'tishini kafolatlaydi. CIsiz CD mumkin emas: agar kod tekshirilmagan bo'lsa, uni reliz qilib bo'lmaydi. CI to'g'rilikni tekshiradi, CD esa biznes foydalanishga tayyorlikni tekshiradi.

Continuous Delivery

CD CIga reliz buildini tayyorlash, metadatalarni tekshirish, imzolash va beta testlash uchun stagingga yoki ilovalar do'koniga joylashtirish bosqichlarini qo'shadi. Asosiy farq — produksiyaga chiqarish to'g'risidagi qarorni inson qabul qiladi (menejer, mahsulot egasi). CD relizni „bir marta bosish“ bilan — sodda va xavfsiz qiladi.

Continuous Deployment

Continuous Deployment — bu to'liq avtomatlashtirish: CD pipeline barcha bosqichlaridan o'tgan har bir o'zgarish qo'lda tasdiqlashsiz avtomatik ravishda produksiyaga yuboriladi. Continuous Deployment SaaS mahsulotlari va veb-servislari uchun qo'llaniladi, lekin ilovalar do'konlari siyosatlari (App Store Review, Google Play Review qo'lda yuborishni talab qiladi) tufayli mobil ishlab chiqishda kam qo'llaniladi.

Mobil ilovalar uchun Continuous Delivery

Mobil ilovalar uchun CD uni veb va backend pipelinelaridan ajratib turadigan xususiyatlarga ega. Mobil relizlar ilovalar do'konlaridan (App Store Review, Google Play Review) o'tadi, bu vaqt va protsessual to'siq qo'shadi. CD reviewga yuborishdan oldin avtomatlashtirish mumkin bo'lgan hammasini avtomatlashtiradi, shunda tekshiruvni birinchi urinishda o'tish ehtimolini maksimal darajada oshiradi.

Google Playda nashr etishga tayyorgarlik

Android CD pipeline quyidagilarni o'z ichiga oladi: AAB (Android App Bundle) yig'ish, reliz kaliti bilan imzolash, R8/ProGuard orqali obfuskatsiya, APK o'lchami va multidex klasslarini tekshirish, reliz eslatmalarini generatsiya qilish. Gradle product flavors (free/paid, dev/staging/prod) ishlatish bitta pipelinedan bir nechta konfiguratsiyalarni boshqarish imkonini beradi.

App Storeda nashr etishga tayyorgarlik

iOS CD Fastlane match orqali sertifikatlar bilan imzolashni, ikonkalarning mosligini tekshirishni (App Store talabi — 1024×1024 px), metadatalarni (nomi, tavsifi, kalit so'zlar) validatsiya qilishni, xususiy APIlar yo'qligini tekshirishni talab qiladi. Texnik validatsiya App Store Connectga yuklamasdan altool --validate-app orqali amalga oshiriladi, bu tezkor fikr-mulohaza beradi.

# Fastfile — iOS va Android uchun to'liq CD pipeline
platform :ios do
  desc "iOS CD — relizni tayyorlash va TestFlightga yuklash"
  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 yig'ish va Google Play Consolega yuklash"
  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 skrinshotlarni yig'adi, match orqali sertifikatlarni oladi, IPA yig'adi va TestFlightga yuklaydi. Android uchun deliver_to_internal leyning Gradle orqali Release AAB yig'adi va uni Google Play Console ichki treykgacha yuklaydi. Ikkala pipeline ham testlardan o'tgandan so'ng CIdan ishga tushiriladi.

CD pipeline komponentlari

CD pipeline ketma-ket bosqichlardan iborat bo'lib, har biri reliz foydalanuvchilarga tayyorligiga ishonch qo'shadi. Bosqichlar texnik (yig'ish, imzolash) va mahsulot (metadata, skrinshotlar, tavsifni tekshirish) guruhlariga bo'linadi. Har qanday bosqichni o'tkazib yuborish ilovalar do'koni tomonidan relizning rad etilishi xavfini oshiradi.

Versiyalarni boshqarish

CDning muhim komponenti — versiyalarni avtomatik boshqarish. Version bump (Android uchun versionCode va versionName, iOS uchun CFBundleVersion va CFBundleShortVersionString) Git tegari yoki do'kondagi avvalgi versiya asosida bajariladi. Fastlane increment_version_number va Gradle buyruqlari (versionCode auto-increment) bu qadamni avtomatlashtiradi.

Do'kon metadatalari

Google Play Console va App Store Connect quyidagilarni talab qiladi: ilova tavsifi, kalit so'zlar, kategoriya, reyting, maxfiylik siyosatiga havolalar. CD o'z ichiga oladi metadatalarning mavjudligi va to'g'riligini tekshirish. Fastlane deliver va supply build bilan birga tavsif, skrinshotlar va ikonkalarni yuklashni avtomatlashtiradi.

Gate tekshiruvlari

Reviewga yuborishdan oldin pipeline gate tekshiruvlarini bajaradi: build o'lchamini tekshirish (200 MB dan katta APK Google Play tomonidan rad etiladi), barcha lokalizatsiyalarning mavjudligi, reliz buildida debug belgilarining yo'qligi, crash-loglarni dekodlash uchun ProGuard mapping faylini tekshirish. Agar birorta tekshiruv o'tmagan bo'lsa — pipeline relizni bloklaydi.

CD uchun avtomatlashtirilgan testlash

CDga ishonch darajasi avtomatik testlar sifatiga to'g'ridan-to'g'ri proporsionaldir. Agar testlar regressiyalarni ushlamasa — reliz produksiyani buzishi mumkin, va jamoa CDga ishonchini yo'qotadi. Mobil CD platforma o'ziga xosligiga moslashtirilgan uch darajali testlash piramidasini talab qiladi.

Birlik testlari

Unit-testlar biznes logikani alohida tekshiradi. Kod qamrovi muhim modullar uchun (autentifikatsiya, to'lovlar, tarmoq bilan ishlash) kamida 70% bo'lishi kerak. CI unit-testlarni har bir pushda ishga tushiradi, va agar ular tushib qolsa — CD pipeline tuzatilgunga qadar bloklanadi.

Integratsion testlar

Komponentlarning o'zaro ta'sirini tekshiradi: haqiqiy API (yoki mock-server) bilan tarmoq qatlami, ma'lumotlar bazasi, fayl tizimi. Android uchun Room DAO testlari, iOS uchun Core Data testlari — integratsion testlar misollaridir. Ular unit-testlardan sekinroq (1–5 daqiqa) va CD bosqichida bajariladi, har bir commitda CIda emas.

UI va skrinshot testlari

Skrinshot testlari (snapshot testing) ilova ekranlarini namunaviy tasvirlar bilan solishtiradi. Agar kod o'zgarishi UI ni o'zgartirgan bo'lsa — test tushadi va dasturchi o'zgarish kutilganmi yoki yo'qligini tekshiradi. Android Roborazzi va Paparazzini qo'llab-quvvatlaydi, iOS — Point-Free SnapshotTestingni. Skrinshot testlari CD pipeline qismi sifatida relizdan oldin bajariladi.

Continuous Delivery bo'yicha eng yaxshi amaliyotlar

Continuous Deliveryni joriy etish nafaqat vositalarni, balki jamoa madaniyatini o'zgartirishni ham talab qiladi. Quyidagi amaliyotlar Google, Spotify va Uberdagi mobil jamoalarning ko'p yillik tajribasiga asoslangan va har qanday o'lchamdagi loyihalarga moslashtirilgan.

Feature flags

Yangi funksiya kodi produksiyaga yetkaziladi, lekin flag orqasida yashiringan. Feature flags funksiya foydalanuvchilarga ko'rsatishga tayyor bo'lishidan oldin kodni chiqarish va muammolar yuzaga kelganda uni bir zumda o'chirish imkonini beradi. Kutubxonalar: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags — mobil loyihalarda CD uchun majburiy shart.

Staging muhiti

Produksiyaga yuborishdan oldin build stagingga joylashtiriladi — produksiya bilan bir xil, lekin test ma'lumotlari bilan muhit. QA muhandislari funksiyani TestFlight yoki Internal Testing treygi orqali o'rnatilgan staging buildida tekshiradi. Agar staging o'tsa — build do'konga reviewga yuborish uchun ruxsat oladi.

Reliz eslatmalari va changelog

CD commit xabarlari asosida reliz eslatmalarini avtomatik generatsiya qiladi. Conventional Commits (feat:, fix:, chore:) va semantic versioning formatidagi Git teglari o'zgarishlar tarixini pars qilish imkonini beradi. Fastlane changelog_from_git_commits oxirgi ikki teg orasidagi o'zgarishlarni yig'adi va ularni ilovalar do'koni uchun formatlaydi.

Relizdan keyingi monitoring

CD nashr qilish bilan tugamaydi — relizdan so'ng monitoring ishga tushadi: crash rate, Android uchun ANR rate, ishga tushirish vaqti, to'lovlardagi muvaffaqiyatsizliklar chastotasi. Agar metrikalar normadan chiqib ketsa — CD pipeline relizni avtomatik qaytarishi yoki jamoani xabardor qilishi kerak. Vositalar: Firebase Crashlytics, Sentry, New Relic.

// CD uchun Firebase Remote Config bilan Feature Flag misoli
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

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

// Kodda ishlatish
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}