Continuous Integration (CI) — vad är det, principer och konfigurering av automatisering

Vad är Continuous Integration

Continuous Integration (CI) — är en utvecklingsmetodik som automatiserar processen för kodintegration från flera deltagare till en enda kodbas. Termen introducerades av Martin Fowler i början av 2000-talet som en uppsättning praxis som förhindrar “integrationshelvetet” — en situation där utvecklare arbetar isolerat i veckor och när ändringarna slås samman uppstår många konflikter som kräver dagar av manuell lösning.

Problemet som CI löser

Utan CI slutför utvecklaren en funktion, försöker slå samman sina ändringar med main-grenen och upptäcker att kollegor har ändrat samma filer. Att lösa konflikter tar timmar och bryter ofta fungerande kod. CI löser detta problem genom tvingad integration flera gånger om dagen: ju oftare integration, desto färre konflikter och lättare att lösa dem. Praktiken visar att vid daglig integration tar konfliktlösning minuter, vid veckovis integration — timmar.

CI:s ekonomiska effekt

Enligt IBM Systems Sciences Institute kostar det $25 att åtgärda ett fel i kodningsfasen, $100 i testfasen och $2 500 i produktionsfasen. CI flyttar defektupptäckt så långt åt vänster som möjligt (shift left) och upptäcker fel i commit-fasen när åtgärden är praktiskt taget gratis. Team med CI lägger i genomsnitt 15% av sin tid på felsökning, jämfört med 35% för team utan CI.

Grundläggande principer för Continuous Integration

Martin Fowler definierade de viktigaste CI-praxis som förblir relevanta oavsett teknikstack. Att följa dessa principer garanterar att CI ger fördelar och inte blir en byråkratisk börda. Mobilutveckling ställer ytterligare krav, men kärnan förblir oförändrad.

Enhetligt förvar

All kod i projektet lagras i ett enda förvar med ett enhetligt versionskontrollsystem (Git). En enda källa till sanning utesluter situationen där en funktion utvecklas i en fork och inte synkroniseras med huvudkodbasen på veckor. I mobilprojekt innebär detta att Android-, iOS- och backend-delar kan finnas i ett förvar (monoförvar) eller i separata förvar med ett gemensamt versionshanteringsschema.

Automatiskt bygge

Bygget av projektet måste utföras med ett enda kommando. För Android är det ./gradlew assembleDebug, för iOS — xcodebuild eller fastlane build. Byggskriptet kontrollerar reproducerbarhet: bygget på CI-servern måste ge samma resultat som på utvecklarens maskin. Eventuella miljöskillnader elimineras genom containerisering eller IaC (Infrastructure as Code).

Automatiska tester

Efter bygget utförs alla testnivåer: modul-, integrations- och UI. Om testerna misslyckas — anses commit vara ogiltig. Att upprätthålla grön status är teamets gemensamma ansvar. I mobilprojekt separeras ofta snabba tester (utförs upp till 5 minuter per commit) och långsamma tester (UI-tester på riktiga enheter, körs mer sällan).

// Exempel på enhetstest med CI-friendly rapport
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 och transparens

CI-resultaten är offentliga för hela teamet: alla ser vems commit som bröt bygget. Transparens skapar en ansvarskultur: utvecklare kontrollerar sina ändringar före push och reparerar det trasiga bygget utanför turordningen. CI-servern skickar meddelanden till Slack eller Telegram när byggstatusen ändras.

Komponenter i CI-systemet

Ett fullfjädrat CI-system består av flera komponenter som samverkar med varandra. Varje komponent ansvarar för sin del av pipeline: från start till rapport. Att förstå CI-arkitekturen hjälper till att diagnostisera problem och optimera prestanda.

CI-server

Den centrala komponenten som hanterar byggkön, resursfördelning och publicering av resultat. CI-servern kan vara molnbaserad (GitHub Actions, GitLab CI, CircleCI) eller self-hosted (Jenkins, TeamCity). Servern övervakar ändringar i förvaret via webhook eller polling och startar pipeline vid varje push eller pull request.

Runners och agenter

Runners är virtuella eller fysiska maskiner som utför bygguppgifter. I moln-CI tillhandahålls runners av leverantören och betalas efter användningstid. Self-hosted runners installeras på egen infrastruktur och kräver underhåll. För iOS-byggen behövs macOS-runners, för Android — Linux eller Windows.

Artefakter och cache

Efter bygget sparar CI-systemet artefakterna (APK, IPA, testrapporter) i lagring — de är tillgängliga för nedladdning och driftsättning. Cachning av beroenden (Gradle cache, CocoaPods cache) mellan körningar påskyndar efterföljande byggen 3–5 gånger.

Continuous Integration för mobilapplikationer

Mobilutveckling ställer särskilda krav på CI, som skiljer sig från webb- eller backendprojekt. Långa byggen (3–15 minuter för Android, 5–20 minuter för iOS), flera artefakttyper (APK, AAB, IPA), behov av signering och obfuskering — allt detta kräver individuell konfiguration av CI-pipelinen.

Android CI-pipeline

Typisk CI för Android omfattar: linting (ktlint, detekt) och statisk analys, enhetstester med JUnit och MockK, bygge av debug och release APK/AAB, instrumenttester på emulator i CI och publicering av artefakter. Gradle-cachen påskyndar upprepade byggen — utan den laddar varje bygge ner beroenden på nytt och förlorar 3–5 minuter.

iOS CI-pipeline

iOS CI kräver en macOS-runner för kompilering av Swift/Objective-C-kod. Pipelinen omfattar: installation av CocoaPods- eller SPM-beroenden, SwiftLint för stilkontroll, enhetstester med XCTest, bygge av IPA, signering av certifikat via Fastlane match och uppladdning till TestFlight. Self-hosted runner på Mac mini eller Mac i ett datacenter — ett alternativ till molnbaserade macOS-runners.

Cross-platform-projekt (Flutter, React Native)

Flutter och React Native kompileras till native-byggen för båda plattformarna. CI måste stödja två runners: Linux för Android-bygge och macOS för iOS-bygge. Optimal strategi — separat pipeline: Android-bygge på Linux-runner, iOS-bygge på macOS-runner, varefter båda artefakterna slås samman till en release.

Jämförelse av CI-verktyg

Valet av CI-verktyg beror på teamstorlek, erforderlig prestanda, budget och teknikstack. Nedan finns en jämförelse av populära lösningar med fokus på mobilutveckling. Self-hosted-lösningar ger kontroll men kräver administration, molnlösningar — bekvämlighet men begränsar konfigurationen.

GitHub Actions

Gratis för offentliga förvar (2000 minuter/månad). GitHub Actions erbjuder ett ekosystem av färdiga actions för Android (gradle/actions) och iOS (apple-actions). Nackdel — macOS-runners är endast tillgängliga i betalda abonnemang. Idealisk för Open Source och små team som redan använder GitHub.

Jenkins

Self-hosted CI-server med öppen källkod. Jenkins konfigureras via Groovy Pipeline, stöder hundratals plugins och fungerar på all hårdvara. Kräver en DevOps-ingenjör för installation och underhåll. Populär inom enterprise-segmentet där kontroll över infrastruktur är kritisk.

GitLab CI

Inbyggd CI/CD i GitLab med öppen runner-arkitektur. GitLab CI tillåter användning av egna runners (inklusive macOS) i det kostnadsfria abonnemanget. YAML-konfiguration är kraftfullare än GitHub Actions men svårare att lära sig. Lämplig för team som använder GitLab som en enda DevOps-plattform.

CircleCI

Moln-CI med fokus på hastighet. CircleCI stöder Docker-, macOS- och Android-images, cachar automatiskt beroenden. Prissättningen är kreditbaserad — dyrare än GitHub Actions för små team, men snabbare tack vare optimerade runners. Rekommenderas för produktionsprojekt med hastighetskrav.

Exempel på CI-konfiguration

Låt oss titta på konfigurationen av CI för ett Android-projekt med GitHub Actions. Pipelinen utför statisk analys, bygge och testning vid varje push och pull request till main-grenen. Minimikonfigurationen tar 15 minuter och kräver inga externa tjänster.

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/

Pipelinen består av två parallella jobb: lint (utför statisk analys) och unit-tests (beror på lint — om linting inte lyckades körs inte testerna). Jobbet unit-tests laddar upp testrapporten som en artefakt — teamet kan visa den i GitHub Actions-gränssnittet utan att ladda ner filer lokalt.

Lokal kontroll före CI

För att undvika CI-fel på grund av triviala fel, konfigurera en pre-push hook i Git eller en Gradle-uppgift som utför samma kontroller lokalt. Till exempel: ./gradlew ktlintCheck detekt testDebugUnitTest. Om lokala kontroller tar mer än 3 minuter — dela upp dem i snabba (linter) och långsamma (tester), kör de snabba före varje commit och de långsamma endast före push.