Continuous Integration (CI) — bu nədir, prinsipləri və avtomatlaşdırmanın qurulması

Continuous Integration nədir

Continuous Integration (CI) — bu, bir neçə iştirakçıdan kodun vahid kod bazasına inteqrasiya prosesini avtomatlaşdıran inkişaf metodologiyasıdır. Termin Martin Fowler tərəfindən 2000-ci illərin əvvəlində „inteqrasiya cəhənnəminin“ qarşısını alan təcrübələr toplusu kimi təqdim edilmişdir — tərtibatçıların həftələrlə təcrid olunmuş şəkildə işlədiyi və dəyişiklikləri birləşdirərkən günlərlə əl ilə həll tələb edən çoxsaylı konfliktlərin yarandığı vəziyyət.

CI-nin həll etdiyi problem

CI olmadan tərtibatçı funksiyanı bitirir, dəyişikliklərini main budağı ilə birləşdirməyə çalışır və həmkarlarının eyni faylları dəyişdirdiyini aşkarlayır. Konfliktlərin həlli saatlar çəkir və tez-tez işləyən kodu sındırır. CI bu problemi gündə bir neçə dəfə məcburi inteqrasiya ilə həll edir: inteqrasiya nə qədər tez-tez olarsa, konfliktlər bir o qədər az və onların həlli bir o qədər asan olar. Təcrübə göstərir ki, gündəlik inteqrasiyada konfliktin həlli dəqiqələr, həftəlik inteqrasiyada isə saatlar çəkir.

CI-nin iqtisadi effekti

IBM Systems Sciences Institute məlumatlarına görə, kod yazma mərhələsində səhvin düzəldilməsi xərci $25, test mərhələsində — $100, istehsal mərhələsində — $2 500 təşkil edir. CI qüsurların aşkarlanmasını mümkün qədər sola (shift left) sürüşdürür, səhvləri commit mərhələsində aşkarlayır, onların düzəldilməsi praktiki olaraq pulsuzdur. CI olan komandalar debug-a orta hesabla 15% vaxt sərf edir, CI olmayan komandalar isə 35%.

Continuous Integration-ın əsas prinsipləri

Martin Fowler texnologiya yığınından asılı olmayaraq aktual qalan CI-nın əsas təcrübələrini müəyyən etmişdir. Bu prinsiplərə riayət etmək CI-nin fayda gətirməsini təmin edir, bürokratik yükə çevrilmir. Mobil inkişaf əlavə tələblər qoyur, lakin əsas dəyişməz qalır.

Vahid repozitoriya

Layihənin bütün kodu vahid versiya idarəetmə sistemi (Git) ilə bir repozitoriyada saxlanılır. Vahid həqiqət mənbəyi funksiyanın fork-da işlənib həftələrlə əsas kod bazası ilə sinxronizasiya olunmadığı vəziyyəti istisna edir. Mobil layihələrdə bu o deməkdir ki, Android, iOS və backend hissələri bir repozitoriyada (monorepozitoriya) və ya ümumi versiyalama sxemi ilə ayrı repozitoriyalarda ola bilər.

Avtomatik qurğu

Layihənin qurulması bir əmrlə yerinə yetirilməlidir. Android üçün ./gradlew assembleDebug, iOS üçün — xcodebuild və ya fastlane build. Qurğu skripti təkrarlanma qabiliyyətini yoxlayır: CI serverində qurğu tərtibatçı maşınındakı ilə eyni nəticəni verməlidir. Mühitdəki hər hansı fərqlər konteynerləşdirmə və ya IaC (Infrastructure as Code) ilə aradan qaldırılır.

Avtomatik testlər

Qurğudan sonra bütün test səviyyələri yerinə yetirilir: modul, inteqrasiya və UI. Testlər uğursuz olarsa — commit etibarsız sayılır. Yaşıl statusun saxlanılması komandanın ümumi məsuliyyətidir. Mobil layihələrdə tez-tez sürətli testlər (hər commit-də 5 dəqiqəyə qədər) və yavaş testlər (real cihazlarda UI testləri, daha az işə salınır) ayrılır.

// CI-friendly hesabatı ilə vahid test nümunəsi
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 və şəffaflıq

CI nəticələri bütün komanda üçün açıqdır: hər kəs kimin commit-inin qurğunu sındırdığını görür. Şəffaflıq məsuliyyət mədəniyyəti yaradır: tərtibatçılar push-dan əvvəl dəyişikliklərini yoxlayır və sındırılmış qurğunu növbədən kənar düzəldirlər. CI serveri qurğu statusu dəyişdikdə Slack və ya Telegram vasitəsilə bildirişlər göndərir.

CI sisteminin komponentləri

Tam hüquqlu CI sistemi bir-biri ilə qarşılıqlı əlaqədə olan bir neçə komponentdən ibarətdir. Hər bir komponent boru kəmərinin öz hissəsinə cavabdehdir: işə salınmadan hesabata qədər. CI arxitekturasını başa düşmək problemləri diaqnoz etməyə və performansı optimallaşdırmağa kömək edir.

CI serveri

Qurğu növbəsini, resurs bölgüsünü və nəticələrin dərcini idarə edən mərkəzi komponent. CI serveri bulud (GitHub Actions, GitLab CI, CircleCI) və ya self-hosted (Jenkins, TeamCity) ola bilər. Server repozitoriyadakı dəyişiklikləri webhook və ya polling vasitəsilə izləyir və hər push və ya pull request-də pipeline işə salır.

Runner-lar və agentlər

Runner-lar — qurğu tapşırıqlarını yerinə yetirən virtual və ya fiziki maşınlardır. Bulud CI-lərdə runner-lar provayder tərəfindən təmin edilir və istifadə vaxtına görə ödənilir. Self-hosted runner-lar öz infrastrukturunda quraşdırılır və texniki xidmət tələb edir. iOS qurğuları üçün macOS runner-ları, Android üçün — Linux və ya Windows lazımdır.

Artefaktlar və keş

Qurğudan sonra CI sistemi artefaktları (APK, IPA, test hesabatları) anbarda saxlayır — onlar endirmə və yerləşdirmə üçün əlçatandır. Keşləmə asılılıqların (Gradle keşi, CocoaPods keşi) işə salmalar arasında saxlanması sonrakı qurğuları 3–5 dəfə sürətləndirir.

Mobil tətbiqlər üçün Continuous Integration

Mobil inkişaf CI-yə web və ya backend layihələrindən fərqli xüsusi tələblər qoyur. Uzun qurğu (Android üçün 3–15 dəqiqə, iOS üçün 5–20 dəqiqə), bir neçə növ artefakt (APK, AAB, IPA), imzalama və obfuskasiya ehtiyacı — bunların hamısı CI pipeline-nın fərdi konfiqurasiyasını tələb edir.

Android CI pipeline

Android üçün tipik CI daxildir: lintinq (ktlint, detekt) və statik analiz, vahid testlər JUnit və MockK ilə, debug və release APK/AAB qurğusu, CI daxilində emulatorda instrumental testlər və artefaktların dərci. Gradle keşi təkrar qurğuları sürətləndirir — onsuz hər qurğu asılılıqları yenidən endirərək 3–5 dəqiqə itirir.

iOS CI pipeline

iOS CI Swift/Objective-C kodunun kompilyasiyası üçün macOS runner tələb edir. Pipeline daxildir: CocoaPods və ya SPM asılılıqlarının quraşdırılması, stil yoxlaması üçün SwiftLint, XCTest ilə vahid testlər, IPA qurğusu, Fastlane match vasitəsilə sertifikatlarla imzalama və TestFlight-a yükləmə. Məlumat mərkəzində Mac mini və ya Mac-da self-hosted runner — bulud macOS runner-larına alternativdir.

Cross-platform layihələr (Flutter, React Native)

Flutter və React Native hər iki platforma üçün native build-lərə kompilyasiya olunur. CI iki runner dəstəkləməlidir: Android qurğusu üçün Linux və iOS qurğusu üçün macOS. Optimal strategiya — ayrılmış pipeline: Linux runner-da Android qurğusu, macOS runner-da iOS qurğusu, bundan sonra hər iki artefakt vahid release-də birləşdirilir.

CI alətlərinin müqayisəsi

CI alətinin seçimi komandanın ölçüsündən, tələb olunan performansdan, büdcədən və texnologiya yığınından asılıdır. Aşağıda mobil inkişafa vurğu ilə məşhur həllərin müqayisəsi verilmişdir. Self-hosted həllər nəzarət verir, lakin administrasiya tələb edir, bulud həllər — rahatlıq verir, lakin konfiqurasiyanı məhdudlaşdırır.

GitHub Actions

İctimai repozitoriyalar üçün pulsuzdur (2000 dəqiqə/ay). GitHub Actions Android (gradle/actions) və iOS (apple-actions) üçün hazır action-lar ekosistemi təklif edir. Minus — macOS runner-ları yalnız ödənişli tariflərdə mövcuddur. Open Source və artıq GitHub istifadə edən kiçik komandalar üçün idealdır.

Jenkins

Açıq mənbə kodu olan self-hosted CI serveri. Jenkins Groovy Pipeline vasitəsilə konfiqurasiya edilir, yüzlərlə plagin dəstəkləyir və istənilən avadanlıqda işləyir. Quraşdırma və dəstək üçün DevOps mühəndisi tələb edir. İnfrastruktur üzərində nəzarətin kritik olduğu enterprise seqmentində məşhurdur.

GitLab CI

GitLab-da açıq runner arxitekturası ilə quraşdırılmış CI/CD. GitLab CI pulsuz tarifdə öz runner-larınızdan (macOS daxil) istifadə etməyə imkan verir. YAML konfiqurasiyası GitHub Actions-dan güclüdür, lakin mənimsənilməsi daha çətindir. GitLab-ı vahid DevOps platforması kimi istifadə edən komandalar üçün uyğundur.

CircleCI

Sürətə vurğu edən bulud CI. CircleCI Docker, macOS və Android image-lərini dəstəkləyir, asılılıqları avtomatik keşləyir. Qiymətləndirmə kredit əsaslıdır — kiçik komandalar üçün GitHub Actions-dan bahadır, lakin optimallaşdırılmış runner-lar sayəsində daha sürətlidir. Sürət tələb edən istehsal layihələri üçün tövsiyə olunur.

CI qurulması nümunəsi

GitHub Actions istifadə edərək Android layihəsi üçün CI qurulmasını nəzərdən keçirək. Pipeline hər push və main budağına pull request-də statik analiz, qurğu və testləri yerinə yetirir. Minimum konfiqurasiya 15 dəqiqə çəkir və xarici xidmətlər tələb etmir.

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/

Pipeline iki paralel job-dan ibarətdir: lint (statik analizi yerinə yetirir) və unit-tests (lint-dən asılıdır — lintinq keçməzsə, testlər işə salınmır). Unit-tests job-u test hesabatını artefakt kimi yükləyir — komanda faylları yerli olaraq endirmədən GitHub Actions interfeysində baxa bilər.

CI-dan əvvəl yerli yoxlama

CI-nin sadə səhvlərə görə uğursuz olmasının qarşısını almaq üçün Git-də pre-push hook və ya eyni yoxlamaları yerli olaraq işə salan Gradle tapşırığı qurun. Məsələn: ./gradlew ktlintCheck detekt testDebugUnitTest. Yerli yoxlamalar 3 dəqiqədən çox çəkirsə — onları sürətli (linter) və yavaş (testlər) olaraq ayırın, sürətliləri hər commit-dən əvvəl, yavaşları isə yalnız push-dan əvvəl işə salın.