Continuous Integration (CI) — bu nima, tamoyillari va avtomatlashtirishni sozlash

Continuous Integration nima

Continuous Integration (CI) — bu bir nechta ishtirokchilardan kodni yagona kod bazasiga integratsiya qilish jarayonini avtomatlashtiradigan ishlab chiqish metodologiyasidir. Atama Martin Fauler tomonidan 2000-yillarning boshlarida „integratsiya do'zaxi"ning oldini oluvchi amaliyotlar to'plami sifatida kiritilgan — dasturchilar haftalar davomida izolyatsiya qilingan holda ishlaydigan va o'zgarishlarni birlashtirganda kunlab qo'lda hal qilishni talab qiladigan ko'plab konfliktlar yuzaga keladigan holat.

CI hal qiladigan muammo

CIsiz dasturchi funksiyani tugatadi, o'zgarishlarini main tarmog'i bilan birlashtirishga harakat qiladi va hamkasblari bir xil fayllarni o'zgartirganini aniqlaydi. Konfliktlarni hal qilish soatlab davom etadi va ko'pincha ishlaydigan kodni buzadi. CI bu muammoni kuniga bir necha marta majburiy integratsiya bilan hal qiladi: integratsiya qanchalik tez-tez bo'lsa, konfliktlar shunchalik kam va ularni hal qilish osonroq bo'ladi. Amaliyot shuni ko'rsatadiki, kundalik integratsiyada konfliktni hal qilish daqiqalar, haftalik integratsiyada esa soatlab davom etadi.

CI-ning iqtisodiy samarasi

IBM Systems Sciences Institute ma'lumotlariga ko'ra, kod yozish bosqichida xatoni tuzatish narxi $25, test bosqichida — $100, ishlab chiqarish bosqichida — $2 500 ni tashkil qiladi. CI nuqsonlarni aniqlashni imkon qadar chapga (shift left) siljitadi, xatolarni commit bosqichida aniqlaydi, ularni tuzatish deyarli bepul. CI bilan ishlaydigan jamoalar nosozliklarni tuzatishga o'rtacha 15% vaqt sarflaydi, CIsiz jamoalar esa 35%.

Continuous Integration-ning asosiy tamoyillari

Martin Fauler texnologiya stekidan qat'iy nazar dolzarb bo'lib qoladigan CI ning asosiy amaliyotlarini belgilagan. Ushbu tamoyillarga rioya qilish CI foyda keltirishini kafolatlaydi, byurokratik yukga aylanmaydi. Mobil ishlab chiqish qo'shimcha talablarni qo'yadi, ammo asos o'zgarishsiz qoladi.

Yagona repozitoriy

Loyihaning barcha kodi yagona versiya boshqaruv tizimi (Git) bilan bitta repozitoriyada saqlanadi. Yagona haqiqat manbai funksiya forkda ishlab chiqilib, haftalar davomida asosiy kod bazasi bilan sinxronlashtirilmagan vaziyatni istisno qiladi. Mobil loyihalarda bu Android, iOS va backend qismlari bitta repozitoriyada (monorepozitoriy) yoki umumiy versiyalash sxemasi bilan alohida repozitoriyalarda bo'lishi mumkinligini anglatadi.

Avtomatik qurish

Loyihani qurish bitta buyruq bilan bajarilishi kerak. Android uchun bu ./gradlew assembleDebug, iOS uchun — xcodebuild yoki fastlane build. Qurish skripti takrorlanuvchanlikni tekshiradi: CI serveridagi qurish dasturchi mashinasidagi bilan bir xil natijani berishi kerak. Muhitdagi har qanday farqlar konteynerlashtirish yoki IaC (Infrastructure as Code) bilan bartaraf etiladi.

Avtomatik testlar

Qurishdan so'ng barcha test darajalari bajariladi: modul, integratsiya va UI. Testlar muvaffaqiyatsiz bo'lsa — commit haqiqiy emas deb hisoblanadi. Yashil holatni saqlash jamoaning umumiy mas'uliyatidir. Mobil loyihalarda tez-tez tezkor testlar (har bir commitda 5 daqiqagacha) va sekin testlar (haqiqiy qurilmalarda UI testlari, kamroq ishga tushiriladi) ajratiladi.

// CI-friendly hisobot bilan birlik test namunasi
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast va shaffoflik

CI natijalari butun jamoa uchun ochiq: har bir kishi kimning commiti qurishni buzganini ko'radi. Shaffoflik mas'uliyat madaniyatini yaratadi: dasturchilar pushdan oldin o'zgarishlarini tekshiradi va buzilgan qurishni navbatdan tashqari tuzatadi. CI serveri qurish holati o'zgarganda Slack yoki Telegram orqali bildirishnomalar yuboradi.

CI tizimining komponentlari

To'liq CI tizimi bir-biri bilan o'zaro aloqada bo'lgan bir nechta komponentlardan iborat. Har bir komponent quvur liniyasining o'z qismiga javobgardir: ishga tushirishdan hisobotgacha. CI arxitekturasini tushunish muammolarni diagnostika qilish va unumdorlikni optimallashtirishga yordam beradi.

CI serveri

Qurish navbatini, resurslarni taqsimlashni va natijalarni nashr qilishni boshqaradigan markaziy komponent. CI serveri bulutli (GitHub Actions, GitLab CI, CircleCI) yoki self-hosted (Jenkins, TeamCity) bo'lishi mumkin. Server repozitoriyadagi o'zgarishlarni webhook yoki polling orqali kuzatadi va har bir push yoki pull requestda quvur liniyasini ishga tushiradi.

Runnerlar va agentlar

Runnerlar — qurish vazifalarini bajaradigan virtual yoki fizik mashinalardir. Bulutli CI-larda runnerlar provayder tomonidan taqdim etiladi va foydalanish vaqtiga qarab to'lanadi. Self-hosted runnerlar o'z infratuzilmangizga o'rnatiladi va texnik xizmat ko'rsatishni talab qiladi. iOS qurishlari uchun macOS runnerlari, Android uchun — Linux yoki Windows kerak.

Artefaktlar va kesh

Qurishdan so'ng CI tizimi artefaktlarni (APK, IPA, test hisobotlari) omborda saqlaydi — ular yuklab olish va joylashtirish uchun mavjud. Keshlash bog'liqliklarni (Gradle keshi, CocoaPods keshi) ishga tushirishlar orasida saqlash keyingi qurishlarni 3–5 marta tezlashtiradi.

Mobil ilovalar uchun Continuous Integration

Mobil ishlab chiqish CI ga web yoki backend loyihalaridan farqli maxsus talablarni qo'yadi. Uzoq qurish (Android uchun 3–15 daqiqa, iOS uchun 5–20 daqiqa), bir nechta artefakt turlari (APK, AAB, IPA), imzolash va obfuskatsiya zarurati — bularning barchasi CI quvur liniyasini individual sozlashni talab qiladi.

Android CI quvur liniyasi

Android uchun odatdagi CI o'z ichiga oladi: linting (ktlint, detekt) va statik tahlil, JUnit va MockK bilan birlik testlari, debug va release APK/AAB qurish, CI ichida emulatorda instrumental testlar va artefaktlarni nashr qilish. Gradle keshi takroriy qurishlarni tezlashtiradi — usiz har bir qurish bog'liqliklarni qayta yuklab, 3–5 daqiqa yo'qotadi.

iOS CI quvur liniyasi

iOS CI Swift/Objective-C kodini kompilyatsiya qilish uchun macOS runner talab qiladi. Quvur liniyasi o'z ichiga oladi: CocoaPods yoki SPM bog'liqliklarini o'rnatish, uslubni tekshirish uchun SwiftLint, XCTest bilan birlik testlari, IPA qurish, Fastlane match orqali sertifikatlar bilan imzolash va TestFlight-ga yuklash. Ma'lumotlar markazidagi Mac mini yoki Mac-da self-hosted runner — bulutli macOS runnerlariga alternativadir.

Cross-platform loyihalar (Flutter, React Native)

Flutter va React Native ikkala platforma uchun native buildlarga kompilyatsiya qilinadi. CI ikki runner ni qo'llab-quvvatlashi kerak: Android qurish uchun Linux va iOS qurish uchun macOS. Optimal strategiya — ajratilgan quvur liniyasi: Linux runnerda Android qurish, macOS runnerda iOS qurish, shundan so'ng ikkala artefakt bitta release-da birlashtiriladi.

CI vositalarini taqqoslash

CI vositasini tanlash jamoa hajmiga, talab qilinadigan unumdorlikka, byudjetga va texnologiya stekiga bog'liq. Quyida mobil ishlab chiqishga urg'u berilgan holda mashhur yechimlarning taqqoslashi keltirilgan. Self-hosted yechimlar nazorat beradi, ammo boshqarishni talab qiladi, bulutli yechimlar — qulaylik, ammo konfiguratsiyani cheklaydi.

GitHub Actions

Ommaviy repozitoriyalar uchun bepul (oyiga 2000 daqiqa). GitHub Actions Android (gradle/actions) va iOS (apple-actions) uchun tayyor actionlar ekotizimini taklif qiladi. Minus — macOS runnerlari faqat pullik tariflarda mavjud. Open Source va allaqachon GitHub-dan foydalanadigan kichik jamoalar uchun ideal.

Jenkins

Ochiq manba kodli self-hosted CI serveri. Jenkins Groovy Pipeline orqali sozlanadi, yuzlab plaginlarni qo'llab-quvvatlaydi va har qanday uskunada ishlaydi. O'rnatish va qo'llab-quvvatlash uchun DevOps muhandisini talab qiladi. Infratuzilma ustidan nazorat muhim bo'lgan enterprise segmentida mashhur.

GitLab CI

GitLab-da ochiq runner arxitekturasi bilan o'rnatilgan CI/CD. GitLab CI bepul tarifda o'z runnerlaringizdan (shu jumladan macOS) foydalanishga imkon beradi. YAML konfiguratsiyasi GitHub Actions-dan kuchliroq, ammo o'zlashtirish qiyinroq. GitLab-ni yagona DevOps platformasi sifatida ishlatadigan jamoalar uchun mos keladi.

CircleCI

Tezlikka urg'u beradigan bulutli CI. CircleCI Docker, macOS va Android tasvirlarini qo'llab-quvvatlaydi, bog'liqliklarni avtomatik keshlaydi. Narxlash kredit asosida — kichik jamoalar uchun GitHub Actions-dan qimmatroq, ammo optimallashtirilgan runnerlar tufayli tezroq. Tezlik talab qiladigan ishlab chiqarish loyihalari uchun tavsiya etiladi.

CI sozlash namunasi

GitHub Actions yordamida Android loyihasi uchun CI sozlashni ko'rib chiqaylik. Quvur liniyasi har bir push va main tarmog'iga pull requestda statik tahlil, qurish va testlarni bajaradi. Minimal konfiguratsiya 15 daqiqa davom etadi va tashqi xizmatlarni talab qilmaydi.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

Quvur liniyasi ikkita parallel job-dan iborat: lint (statik tahlilni bajaradi) va unit-tests (lint-ga bog'liq — linting o'tmasa, testlar ishga tushirilmaydi). Unit-tests job-i test hisobotini artefakt sifatida yuklaydi — jamoa fayllarni mahalliy yuklab olmasdan GitHub Actions interfeysida ko'rishi mumkin.

CI dan oldin mahalliy tekshirish

CI ning oddiy xatolar tufayli ishlamay qolishini oldini olish uchun Git-da pre-push hook yoki bir xil tekshiruvlarni mahalliy bajaradigan Gradle vazifasini sozlang. Masalan: ./gradlew ktlintCheck detekt testDebugUnitTest. Mahalliy tekshiruvlar 3 daqiqadan ko'proq davom etsa — ularni tezkor (linter) va sekin (testlar) ga ajrating, tezkorlarini har bir commitdan oldin, sekinlarini esa faqat pushdan oldin ishga tushiring.