CI/CD Pipeline — bu nima, avtomatlashtirish bosqichlari va vositalar

CI/CD Pipeline nima

CI/CD Pipeline — bu kod omborda o‘zgarishlarni tasdiqlash vaqtidan ishlab chiqarishga joylashtirilgunga qadar o‘tadigan rasmiylashtirilgan va avtomatlashtirilgan jarayonlar to‘plamidir. Bu atama ikkita amaliyotni birlashtiradi: Continuous Integration (uzluksiz integratsiya) va Continuous Delivery (uzluksiz yetkazib berish), ular birgalikda dasturiy ta’minot yetkazib berish quvurini tashkil qiladi.

CI/CD ning paydo bo‘lish tarixi

Continuous Integration kontseptsiyasi 1991 yilda Gradi Bouch tomonidan tasvirlangan va 2000-yillarda Martin Fauler tomonidan ommalashtirilgan. Continuous Delivery atamasi Jez Humble va Devid Farleyning “Continuous Delivery” (2010) kitobidan keyin mustahkamlangan. Zamonaviy CI/CD Pipeline 2015 yildan keyin mobil ilova ishlab chiqishda de-fakto standartga aylandi — bulutli CI serverlari va ilova do‘konlarining avtomatlashtirilishi bilan.

Mobil ilova ishlab chiqishda CI/CD Pipeline nima uchun kerak

Mobil ilovalar qurish va nashr qilish uchun maxsus talablarga ega: sertifikatlar bilan imzolash, bir necha konfiguratsiyalar (debug, release, staging), ProGuard/R8 obfuskatsiyasi, bir necha build turlari (APK, AAB, IPA) va ilova do‘konlari bilan integratsiya. Bu qadamlarni qo‘lda bajarish soatlab vaqt oladi va xatolarga moyil — CI/CD Pipeline odatdagi ishlarni avtomatlashtiradi.

Mobil ilovalar uchun CI/CD Pipeline bosqichlari

Android yoki iOS ilovasi uchun standart CI/CD Pipeline yettita asosiy bosqichdan iborat. Ba’zi bosqichlar parallel, boshqalari ketma-ket bajariladi. Bosqichlarning aniq tarkibi texnologik stek va jamoaning yetukligiga bog‘liq, ammo asosiy qism o‘zgarishsiz qoladi.

1. Checkout va bog‘liqliklarni o‘rnatish

Quvur omborni klonlash va bog‘liqliklarni o‘rnatish bilan boshlanadi: Android uchun Gradle/Maven, iOS uchun CocoaPods yoki SPM. Bog‘liqliklarni keshlash ishga tushirishlar orasida o‘rnatish vaqtini 3–5 daqiqadan bir necha soniyaga qisqartiradi — bu optimallashtirishni barcha zamonaviy CI xizmatlari qo‘llab-quvvatlaydi.

2. Statik tahlil va linting

Qurishdan oldin kod linterlar (Android uchun ktlint, detekt, iOS uchun SwiftLint) va statik analizatorlar (Android Lint, SonarQube) tomonidan tekshiriladi. Linting testlarni ishga tushirishdan oldin potentsial xatolarni, kod uslubi buzilishlarini va eskirgan API-larni aniqlaydi — fail-fast printsipi jamoaning vaqtini tejaydi.

3. Loyihani qurish

Qurish bosqichida butun loyiha kompilyatsiya qilinadi va artefaktlar yaratiladi: Android uchun APK va AAB, iOS uchun IPA. Android uchun Gradle vazifalari (assembleDebug, bundleRelease), iOS uchun xcodebuild yoki xcrun ishlatiladi. Qurish CI serverining izolyatsiyalangan muhitida amalga oshiriladi, bu takrorlanuvchanlikni kafolatlaydi.

# GitHub Actions da Android uchun CI/CD Pipeline misoli
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Avtomatik testlash

Qurishdan keyin birlik testlari, integratsiya testlari va UI testlari ishga tushiriladi. JUnit va MockK modul testlari uchun, Espresso va Compose Test Android-da UI uchun, XCTest va XCUITest iOS-da. Natijalar hisobotda e’lon qilinadi va muhim testlar muvaffaqiyatsiz bo‘lsa, quvurni bloklaydi.

5. Imzolash va obfuskatsiya

Reliz buildlari uchun raqamli sertifikat bilan imzolash (Android uchun APK Signer, iOS uchun codesign) va kod obfuskatsiyasi amalga oshiriladi. ProGuard yoki R8 Android uchun APK hajmini 15–30% kamaytiradi. Imzo kalitlari CI serverining sirlarida saqlanadi — hech qachon omborga commit qilinmaydi.

6. Yetkazib berish va joylashtirish

Quvurning yakuniy bosqichi — artefaktlarni nashr qilish: APKni Google Play Console ichki testiga yuklash, IPAni TestFlight‘ga jo‘natish yoki Firebase Distribution‘da nashr qilish. Continuous Delivery bu qadam qo‘lda tasdiqlashni talab qilishini nazarda tutadi, Continuous Deployment esa avtomatik bajariladi.

7. Bildirishnomalar va hisobotlar

Quvur tugagandan so‘ng, jamoa natijalar bilan bildirishnoma oladi: muvaffaqiyat/muvaffaqiyatsizlik, bajarilish vaqti, artefaktlarga havola. Slack, Telegram yoki email — bildirishnoma kanallari jamoaning ehtiyojlariga qarab tanlanadi. Bosqich muvaffaqiyatsiz bo‘lsa, bildirishnomaga aniq xato jurnaliga havola kiritiladi.

CI ning CD dan farqi nima

CI va CD atamalari ko‘pincha yagona CI/CD tushunchasi sifatida ishlatiladi, ammo ular orasida tub farq bor. CI (Continuous Integration) har bir kod integratsiyasida sifatni tekshirish uchun javobgar, CD (Continuous Delivery) esa bu kodning relizga tayyorligini ta’minlaydi. Farqni tushunish quvurni loyihalashda muhim ahamiyatga ega.

Continuous Integration — sifat nazorati

CI har bir push yoki pull requestda bajariladi va qurish, statik tahlil va testlashni o‘z ichiga oladi. CI ning maqsadi — muammolarni iloji boricha erta, ularni tuzatish narxi minimal bo‘lganda aniqlash. Agar CI o‘tmasa — kod asosiy tarmoqqa kirmaydi. Mobil loyiha uchun CI ning o‘rtacha bajarilish vaqti 5–15 daqiqa.

Continuous Delivery — relizga tayyorlik

CD CI‘ga reliz tayyorlash bosqichlarini qo‘shadi: imzolash, obfuskatsiya, reliz eslatmalarini yaratish, litsenziyalarni tekshirish, testerlar uchun omborda nashr qilish. CD kafolatlaydiki, asosiy tarmoqdagi har bir commit bir marta bosish bilan ishlab chiqarishga joylashtirilishi mumkin, ammo relizning o‘zi qo‘lda tasdiqlashni talab qiladi.

CI/CD Pipeline qurish vositalari

Mobil ilova ishlab chiqish uchun CI/CD vositalari ekotizimiga bulutli xizmatlar, self-hosted yechimlar va ixtisoslashgan platformalar kiradi. Vositani tanlash jamoa hajmi, byudjet va xavfsizlik talablariga bog‘liq. Quyida eng mashhur variantlar keltirilgan.

GitHub Actions

GitHub‘ga o‘rnatilgan CI/CD, umumiy omborlar uchun oyiga 2000 daqiqa bepul limit bilan. GitHub Actions tayyor action‘larning (marketplace) ulkan ekotizimi, YAML orqali sodda sozlash va GitHub ombori bilan muammosiz integratsiya tufayli mashhur. Cheklov — bepul tarifda iOS buildlari uchun Windows runnerlarining qo‘llab-quvvatlanmasligi.

GitLab CI/CD

Self-hosted va bulutli yechim kuchli YAML konfiguratori bilan. GitLab CI parallel job‘larni, keshlashni, artefaktlarni va muhitlarni (environments) qo‘llab-quvvatlaydi. O‘z infratuzilmasida joylashtirish imkoniyati va ma’lumotlar ustidan to‘liq nazorat tufayli enterprise segmentida mashhur.

Jenkins

Ochiq manbali klassik CI server. Jenkins plaginlar (1800 dan ortiq) orqali sozlanadi, Groovy formatida Declarative Pipeline‘ni qo‘llab-quvvatlaydi va istalgan muhitda ishlaydi: Windows, macOS, Linux. Maxsus administratsiyani talab qiladi, lekin maksimal sozlash moslashuvchanligini beradi.

CircleCI

Tezlik va soddalikka urg‘u beruvchi bulutli CI xizmati. CircleCI avtomatik ravishda bog‘liqliklarni keshlaydi, izolyatsiyalangan buildlar uchun Docker tasvirlarini va iOS buildlari uchun macOS bilan integratsiyani qo‘llab-quvvatlaydi. Narxlash kreditlar soniga asoslangan — unumdorlikni qadrlaydigan jamoalar uchun mos.

CI/CD Pipeline sozlash misoli

GitHub Actions va Fastlane yordamida iOS ilovasi uchun to‘liq CI/CD Pipeline‘ni ko‘rib chiqaylik. Fastlane — mobil loyihalar uchun avtomatlashtirish vositasi bo‘lib, murakkab qurish, imzolash va nashr qilish operatsiyalarini sodda buyruqlarga abstraksiya qiladi.

# Fastfile — iOS CI/CD uchun Fastlane konfiguratsiyasi
default_platform(:ios)

platform :ios do
  desc "Testlar va lintni ishga tushirish"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Relizni qurish va TestFlight ga yuklash"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match sertifikatlar va provisioning profiles‘ni boshqaradi, build_app IPA‘ni quradi, pilot buildni TestFlight‘ga yuklaydi. fastlane release buyrug‘i barcha bosqichlarni ketma-ket bajaradi: sertifikatlarni oladi, quradi, imzolaydi, beta testerlar uchun App Store Connect‘ga yuklaydi.

GitHub Actions bilan iOS uchun CI/CD Pipeline

Fastlane‘ning GitHub Actions bilan integratsiyasi main tarmog‘iga pull requestda to‘liq quvurni avtomatik ishga tushirishga imkon beradi. macOS‘da self-hosted runner iOS kodini kompilyatsiya qilish uchun zarur — GitHub bepul tarifda macOS runnerlarini taqdim etmaydi.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

CI/CD Pipeline uchun eng yaxshi amaliyotlar

Samarali CI/CD Pipeline qurish nafaqat vositalarni tanlash, balki isbotlangan amaliyotlarga amal qilishni ham talab qiladi. To‘g‘ri tashkil etilmasa, quvur rivojlanishni tezlashtirish o‘rniga uni sekinlashtiradigan tor joyga aylanishi mumkin. Quyida — yetuk mobil jamoalar tajribasiga asoslangan asosiy tavsiyalar.

Fail fast

Eng tezkor tekshiruvlar (linting, birlik testlari) birinchi bajariladi. Agar ular muvaffaqiyatsiz bo‘lsa — quvur uzoq UI testlari yoki reliz qurilishini ishga tushirmasdan tugaydi. Fail fast CI daqiqalarini tejaydi va dasturchiga qayta aloqani tezlashtiradi. Birinchi muvaffaqiyatsizlikka qadar o‘rtacha vaqt 2–3 daqiqadan oshmasligi kerak.

Bog‘liqliklarni keshlash

Gradle keshi, CocoaPods keshi va SPM keshi ishga tushirishlar orasida tiklanishi kerak. GitHub Actions keshlashni actions/cache orqali, GitLab CI — cache kalit so‘zi orqali qo‘llab-quvvatlaydi. Keshlashsiz har bir qurish barcha bog‘liqliklarni qayta yuklaydi — bu quvur vaqtiga 3–10 daqiqa qo‘shadi.

Parallel bajarish

Mustaqil bosqichlar (Android va iOS uchun linter, turli modullarning birlik testlari) parallel job‘lar sifatida ishga tushiriladi. Parallellashtirish quvurning umumiy vaqtini 20–30 daqiqadan 5–10 daqiqaga qisqartiradi. Aksariyat CI xizmatlari parallel job‘larni alohida hisoblaydi ‘‘ tarif rejasini tanlashda buni hisobga oling.

Muhitni izolyatsiya qilish

Quvurning har bir ishga tushirilishi toza muhitda amalga oshiriladi: Docker konteynerida, virtual mashinada yoki vaqtinchalik runnerda. Izolyatsiya oldingi buildlarning joriy buildga ta’sirini oldini oladi. Loyihalar orasida umumiy runnerlardan foydalanishdan saqlaning — loyihalararo muhit ifloslanishi noaniq nosozliklarga olib keladi.

Sirlar xavfsizligi

API kalitlari, imzo sertifikatlari va ilova do‘konlariga kirish tokenlari CI serverining shifrlangan omborida saqlanadi. Hech qachon sirlarni jurnallarga, artefaktlarga yoki SECRET_ prefiksisiz muhit o‘zgaruvchilariga kiritmang. iOS sertifikatlarini boshqarish uchun Fastlane match kabi vositalardan foydalaning.