Continuous Integration (CI) — co to jest, zasady i konfiguracja automatyzacji

Co to jest Continuous Integration

Continuous Integration (CI) — to metodologia programistyczna automatyzująca proces integracji kodu od wielu uczestników w jedną bazę kodu. Termin został wprowadzony przez Martina Fowlera na początku lat 2000. jako zestaw praktyk zapobiegających „piekłu integracji” — sytuacji, w której programiści pracują w izolacji tygodniami, a podczas łączenia zmian powstaje wiele konfliktów wymagających dni ręcznego rozwiązywania.

Problem, który rozwiązuje CI

Bez CI programista kończy funkcję, próbuje scalić swoje zmiany z gałęzią main i odkrywa, że koledzy zmienili te same pliki. Rozwiązywanie konfliktów zajmuje godziny i często psuje działający kod. CI rozwiązuje ten problem poprzez wymuszoną integrację kilka razy dziennie: im częstsza integracja, tym mniej konfliktów i łatwiejsze ich rozwiązywanie. Praktyka pokazuje, że przy codziennej integracji rozwiązanie konfliktu zajmuje minuty, a przy cotygodniowej — godziny.

Efekt ekonomiczny CI

Według IBM Systems Sciences Institute, koszt naprawy błędu na etapie pisania kodu wynosi $25, na etapie testowania — $100, na etapie produkcyjnym — $2 500. CI przesuwa wykrywanie defektów maksymalnie w lewo (shift left), wykrywając błędy na etapie commita, gdy ich naprawa jest praktycznie darmowa. Zespoły z CI spędzają na debugowaniu średnio 15% czasu wobec 35% u zespołów bez CI.

Podstawowe zasady Continuous Integration

Martin Fowler określił kluczowe praktyki CI, które pozostają aktualne niezależnie od stosu technologicznego. Przestrzeganie tych zasad gwarantuje, że CI przynosi korzyści, a nie staje się obciążeniem biurokratycznym. Rozwój mobilny nakłada dodatkowe wymagania, ale rdzeń pozostaje niezmienny.

Jedno repozytorium

Cały kod projektu przechowywany jest w jednym repozytorium z jednym systemem kontroli wersji (Git). Jeden źródło prawdy eliminuje sytuację, w której funkcja jest rozwijana w forku i nie synchronizuje się z główną bazą kodu przez tygodnie. W projektach mobilnych oznacza to, że części Android, iOS i backend mogą znajdować się w jednym repozytorium (monorepozytorium) lub w oddzielnych repozytoriach z wspólnym schematem wersjonowania.

Automatyczna kompilacja

Kompilacja projektu powinna być wykonywana jednym poleceniem. Dla Android jest to ./gradlew assembleDebug, dla iOS — xcodebuild lub fastlane build. Skrypt kompilacji sprawdza powtarzalność: kompilacja na serwerze CI powinna dawać ten sam wynik co na maszynie programisty. Wszelkie różnice w środowisku eliminuje się poprzez konteneryzację lub IaC (Infrastructure as Code).

Automatyczne testy

Po kompilacji wykonywane są wszystkie poziomy testów: modułowe, integracyjne i UI. Jeśli testy padają — commit jest uważany za nieważny. Utrzymanie zielonego statusu to wspólna odpowiedzialność zespołu. W projektach mobilnych często rozdziela się szybkie testy (wykonywane do 5 minut na każdy commit) i wolne testy (testy UI na rzeczywistych urządzeniach, uruchamiane rzadziej).

// Przykład testu jednostkowego z raportem 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 przejrzystość

Wyniki CI są publiczne dla całego zespołu: każdy widzi, czyj commit zepsuł kompilację. Przejrzystość tworzy kulturę odpowiedzialności: programiści sprawdzają swoje zmiany przed push-em i naprawiają zepsutą kompilację poza kolejnością. Serwer CI wysyła powiadomienia do Slacka lub Telegrama przy zmianie statusu kompilacji.

Komponenty systemu CI

Pełnoprawny system CI składa się z kilku komponentów współdziałających ze sobą. Każdy komponent odpowiada za swoją część potoku: od uruchomienia po raport. Zrozumienie architektury CI pomaga diagnozować problemy i optymalizować wydajność.

Serwer CI

Centralny komponent zarządzający kolejką kompilacji, dystrybucją zasobów i publikacją wyników. Serwer CI może być chmurowy (GitHub Actions, GitLab CI, CircleCI) lub self-hosted (Jenkins, TeamCity). Serwer śledzi zmiany w repozytorium przez webhook lub polling i uruchamia pipeline przy każdym push-u lub pull requeście.

Runnery i agenty

Runnery — to wirtualne lub fizyczne maszyny wykonujące zadania kompilacji. W chmurowych CI runnery są dostarczane przez providera i płatne według czasu użycia. Self-hosted runnery instalowane są na własnej infrastrukturze i wymagają utrzymania. Dla kompilacji iOS potrzebne są runnery macOS, dla Android — Linux lub Windows.

Artefakty i cache

Po kompilacji system CI zapisuje artefakty (APK, IPA, raporty testów) w magazynie — są dostępne do pobrania i wdrożenia. Cache'owanie zależności (Gradle cache, CocoaPods cache) między uruchomieniami przyspiesza kolejne kompilacje 3–5 razy.

Continuous Integration dla aplikacji mobilnych

Rozwój mobilny stawia szczególne wymagania wobec CI, różne od projektów webowych czy backendowych. Długa kompilacja (3–15 minut dla Android, 5–20 minut dla iOS), kilka typów artefaktów (APK, AAB, IPA), konieczność podpisywania i obfuskacji — wszystko to wymaga indywidualnej konfiguracji pipeline'a CI.

Pipeline CI dla Android

Typowy CI dla Android obejmuje: linting (ktlint, detekt) i analizę statyczną, testy jednostkowe z JUnit i MockK, kompilację debug i release APK/AAB, testy instrumentalne na emulatorze w CI oraz publikację artefaktów. Cache Gradle przyspiesza ponowne kompilacje — bez niego każda kompilacja pobiera zależności od nowa, tracąc 3–5 minut.

Pipeline CI dla iOS

iOS CI wymaga runnera macOS do kompilacji kodu Swift/Objective-C. Pipeline obejmuje: instalację zależności CocoaPods lub SPM, SwiftLint do sprawdzania stylu, testy jednostkowe z XCTest, kompilację IPA, podpisywanie certyfikatami przez Fastlane match i przesyłanie do TestFlight. Self-hosted runner na Mac mini lub Mac w centrum danych — alternatywa dla chmurowych runnerów macOS.

Projekty cross-platformowe (Flutter, React Native)

Flutter i React Native kompilują się do natywnych buildów dla obu platform. CI musi obsługiwać dwa runnery: Linux dla kompilacji Android i macOS dla kompilacji iOS. Optymalna strategia — rozdzielony pipeline: kompilacja Android na runnerze Linux, kompilacja iOS na runnerze macOS, po czym oba artefakty łączone są w jeden release.

Porównanie narzędzi CI

Wybór narzędzia CI zależy od wielkości zespołu, wymaganej wydajności, budżetu i stosu technologicznego. Poniżej znajduje się porównanie popularnych rozwiązań z naciskiem na rozwój mobilny. Rozwiązania self-hosted dają kontrolę, ale wymagają administracji, chmurowe — wygodę, ale ograniczają konfigurację.

GitHub Actions

Bezpłatny dla publicznych repozytoriów (2000 minut/miesiąc). GitHub Actions oferuje ekosystem gotowych akcji dla Android (gradle/actions) i iOS (apple-actions). Minus — runnery macOS dostępne tylko w płatnych taryfach. Idealny dla Open Source i małych zespołów już korzystających z GitHub.

Jenkins

Self-hosted serwer CI z otwartym kodem źródłowym. Jenkins konfiguruje się przez Groovy Pipeline, obsługuje setki wtyczek i działa na dowolnym sprzęcie. Wymaga inżyniera DevOps do instalacji i utrzymania. Popularny w segmencie enterprise, gdzie kluczowa jest kontrola nad infrastrukturą.

GitLab CI

Wbudowany CI/CD w GitLab z otwartą architekturą runnerów. GitLab CI pozwala używać własnych runnerów (w tym macOS) w bezpłatnej taryfie. Konfiguracja YAML jest potężniejsza niż GitHub Actions, ale trudniejsza do opanowania. Odpowiedni dla zespołów używających GitLab jako jednej platformy DevOps.

CircleCI

Chmurowy CI z naciskiem na szybkość. CircleCI obsługuje obrazy Docker, macOS i Android, automatycznie cache'uje zależności. Cennik kredytowy — droższy niż GitHub Actions dla małych zespołów, ale szybszy dzięki zoptymalizowanym runnerom. Zalecany dla projektów produkcyjnych z wymogami szybkości.

Przykład konfiguracji CI

Rozważmy konfigurację CI dla projektu Android z użyciem GitHub Actions. Pipeline wykonuje analizę statyczną, kompilację i testowanie przy każdym push-u i pull requeście do gałęzi main. Minimalna konfiguracja zajmuje 15 minut i nie wymaga zewnętrznych usług.

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 składa się z dwóch równoległych jobów: lint (wykonuje analizę statyczną) i unit-tests (zależy od lint — jeśli linting nie przeszedł, testy nie są uruchamiane). Job unit-tests przesyła raport testów jako artefakt — zespół może go przeglądać w interfejsie GitHub Actions bez pobierania plików lokalnie.

Lokalne sprawdzenie przed CI

Aby uniknąć awarii CI z powodu trywialnych błędów, skonfiguruj pre-push hook w Git lub zadanie Gradle uruchamiające te same sprawdzenia lokalnie. Na przykład: ./gradlew ktlintCheck detekt testDebugUnitTest. Jeśli lokalne sprawdzenia zajmują więcej niż 3 minuty — podziel je na szybkie (linter) i wolne (testy), uruchamiając szybkie przed każdym commitem, a wolne tylko przed push-em.