Continuous Integration (CI) — ce este, principii și configurarea automatizării

Ce este Continuous Integration

Continuous Integration (CI) — este o metodologie de dezvoltare care automatizează procesul de integrare a codului de la mai mulți participanți într-o singură bază de cod. Termenul a fost introdus de Martin Fowler la începutul anilor 2000 ca un set de practici care previn „iadul integrării” — situația în care dezvoltatorii lucrează izolat săptămâni întregi, iar la îmbinarea modificărilor apar numeroase conflicte care necesită zile de rezolvare manuală.

Problema pe care o rezolvă CI

Fără CI, dezvoltatorul termină o funcționalitate, încearcă să îmbine modificările cu branch-ul main și descoperă că colegii au modificat aceleași fișiere. Rezolvarea conflictelor durează ore și deseori strică codul funcțional. CI rezolvă această problemă prin integrarea forțată de mai multe ori pe zi: cu cât integrarea este mai frecventă, cu atât mai puține conflicte și mai ușoară rezolvarea lor. Practica arată că la integrarea zilnică, rezolvarea unui conflict durează minute, iar la cea săptămânală — ore.

Efectul economic al CI

Potrivit IBM Systems Sciences Institute, costul remedierii unei erori în faza de scriere a codului este de $25, în faza de testare — $100, în faza de producție — $2 500. CI deplasează detectarea defectelor cât mai la stânga (shift left), identificând erorile în faza de commit, când remedierea lor este practic gratuită. Echipele cu CI petrec în medie 15% din timp pe depanare, față de 35% la echipele fără CI.

Principiile de bază ale Continuous Integration

Martin Fowler a definit practicile-cheie ale CI care rămân valabile indiferent de stiva tehnologică. Respectarea acestor principii garantează că CI aduce beneficii, nu devine o povară birocratică. Dezvoltarea mobilă impune cerințe suplimentare, dar nucleul rămâne neschimbat.

Depozit unic

Întregul cod al proiectului este stocat într-un singur depozit cu un sistem unic de control al versiunilor (Git). Sursa unică de adevăr exclude situația în care o funcționalitate este dezvoltată într-un fork și nu se sincronizează cu baza de cod principală săptămâni întregi. În proiectele mobile, aceasta înseamnă că părțile Android, iOS și backend pot fi într-un singur depozit (monorepozitoriu) sau în depozite separate cu o schemă comună de versionare.

Compilare automată

Compilarea proiectului trebuie executată cu o singură comandă. Pentru Android este ./gradlew assembleDebug, pentru iOS — xcodebuild sau fastlane build. Scriptul de compilare verifică reproductibilitatea: compilarea pe serverul CI trebuie să dea același rezultat ca pe mașina dezvoltatorului. Orice diferențe de mediu sunt eliminate prin containerizare sau IaC (Infrastructure as Code).

Teste automate

După compilare se execută toate nivelurile de teste: module, integrare și UI. Dacă testele eșuează — commit-ul este considerat nevalid. Menținerea statusului verde este responsabilitatea comună a echipei. În proiectele mobile, se separă adesea testele rapide (executate până la 5 minute la fiecare commit) și testele lente (teste UI pe dispozitive reale, rulate mai rar).

// Exemplu de test unitar cu raport CI-friendly
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 și transparență

Rezultatele CI sunt publice pentru întreaga echipă: toată lumea vede al cui commit a stricat compilarea. Transparența creează o cultură a responsabilității: dezvoltatorii își verifică modificările înainte de push și repară compilarea stricată în afara rândului. Serverul CI trimite notificări în Slack sau Telegram la schimbarea statusului compilării.

Componentele sistemului CI

Un sistem CI complet este format din mai multe componente care interacționează între ele. Fiecare componentă răspunde de partea sa din conductă: de la lansare până la raport. Înțelegerea arhitecturii CI ajută la diagnosticarea problemelor și optimizarea performanței.

Serverul CI

Componenta centrală care gestionează coada de compilări, distribuția resurselor și publicarea rezultatelor. Serverul CI poate fi cloud (GitHub Actions, GitLab CI, CircleCI) sau self-hosted (Jenkins, TeamCity). Serverul urmărește modificările din depozit prin webhook sau polling și lansează pipeline-ul la fiecare push sau pull request.

Runners și agenți

Runners — sunt mașini virtuale sau fizice care execută sarcinile de compilare. În CI-urile cloud, runnerii sunt furnizați de provider și se plătesc în funcție de timpul de utilizare. Runnerii self-hosted se instalează pe propria infrastructură și necesită întreținere. Pentru compilările iOS sunt necesari runneri macOS, pentru Android — Linux sau Windows.

Artefacte și cache

După compilare, sistemul CI salvează artefactele (APK, IPA, rapoarte de teste) în depozit — acestea sunt disponibile pentru descărcare și implementare. Cache-ul dependențelor (Gradle cache, CocoaPods cache) între rulări accelerează compilările ulterioare de 3–5 ori.

Continuous Integration pentru aplicații mobile

Dezvoltarea mobilă impune cerințe speciale pentru CI, diferite de proiectele web sau backend. Compilarea lungă (3–15 minute pentru Android, 5–20 minute pentru iOS), mai multe tipuri de artefacte (APK, AAB, IPA), necesitatea semnării și ofuscării — toate necesită o configurare individuală a pipeline-ului CI.

Pipeline CI pentru Android

CI tipic pentru Android include: linting (ktlint, detekt) și analiză statică, teste unitare cu JUnit și MockK, compilarea debug și release APK/AAB, teste instrumentale pe emulator în CI și publicarea artefactelor. Cache-ul Gradle accelerează compilările repetate — fără el, fiecare compilare descarcă dependențele din nou, pierzând 3–5 minute.

Pipeline CI pentru iOS

iOS CI necesită un runner macOS pentru compilarea codului Swift/Objective-C. Pipeline-ul include: instalarea dependențelor CocoaPods sau SPM, SwiftLint pentru verificarea stilului, teste unitare cu XCTest, compilarea IPA, semnarea certificatelor prin Fastlane match și încărcarea în TestFlight. Runnerul self-hosted pe Mac mini sau Mac într-un centru de date — alternativă la runnerii cloud macOS.

Proiecte cross-platform (Flutter, React Native)

Flutter și React Native se compilează în build-uri native pentru ambele platforme. CI trebuie să suporte doi runneri: Linux pentru compilarea Android și macOS pentru compilarea iOS. Strategia optimă — pipeline separat: compilarea Android pe runner Linux, compilarea iOS pe runner macOS, după care ambele artefacte sunt combinate într-un singur release.

Compararea instrumentelor CI

Alegerea instrumentului CI depinde de dimensiunea echipei, performanța necesară, buget și stiva tehnologică. Mai jos este o comparație a soluțiilor populare cu accent pe dezvoltarea mobilă. Soluțiile self-hosted oferă control, dar necesită administrare, cele cloud — confort, dar limitează configurația.

GitHub Actions

Gratuit pentru depozite publice (2000 de minute/lună). GitHub Actions oferă un ecosistem de acțiuni gata făcute pentru Android (gradle/actions) și iOS (apple-actions). Minus — runnerii macOS sunt disponibili doar la tarifele plătite. Ideal pentru Open Source și echipe mici care folosesc deja GitHub.

Jenkins

Server CI self-hosted cu cod sursă deschis. Jenkins se configurează prin Groovy Pipeline, suportă sute de pluginuri și funcționează pe orice hardware. Necesită un inginer DevOps pentru instalare și întreținere. Popular în segmentul enterprise, unde controlul infrastructurii este critic.

GitLab CI

CI/CD încorporat în GitLab cu arhitectură deschisă de runneri. GitLab CI permite utilizarea propriilor runneri (inclusiv macOS) în tariful gratuit. Configurarea YAML este mai puternică decât GitHub Actions, dar mai dificil de învățat. Potrivit pentru echipele care folosesc GitLab ca platformă unică DevOps.

CircleCI

CI cloud cu accent pe viteză. CircleCI suportă imagini Docker, macOS și Android, face automat cache la dependențe. Prețurile sunt pe bază de credite — mai scump decât GitHub Actions pentru echipe mici, dar mai rapid datorită runnerilor optimizați. Recomandat pentru proiecte de producție cu cerințe de viteză.

Exemplu de configurare CI

Să analizăm configurarea CI pentru un proiect Android folosind GitHub Actions. Pipeline-ul execută analiză statică, compilare și testare la fiecare push și pull request în branch-ul main. Configurarea minimă durează 15 minute și nu necesită servicii externe.

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-ul constă din două job-uri paralele: lint (execută analiza statică) și unit-tests (depinde de lint — dacă linting-ul nu a trecut, testele nu se execută). Job-ul unit-tests încarcă raportul de teste ca artefact — echipa îl poate vizualiza în interfața GitHub Actions fără a descărca fișierele local.

Verificare locală înainte de CI

Pentru a evita căderea CI din cauza erorilor simple, configurați un pre-push hook în Git sau o sarcină Gradle care execută aceleași verificări local. De exemplu: ./gradlew ktlintCheck detekt testDebugUnitTest. Dacă verificările locale durează mai mult de 3 minute — împărțiți-le în rapide (linter) și lente (teste), rulându-le pe cele rapide înainte de fiecare commit, iar pe cele lente doar înainte de push.