CI/CD och automatisering inom mobilutveckling: vad det är, hur det fungerar och varför det behövs

Vad är CI/CD?

Continuous Integration

Continuous Integration är grunden för CI/CD-automatisering för mobilappar. Det är en praxis där varje utvecklare slår samman sin kod i ett delat repository flera gånger om dagen. Efter varje push bygger CI-servern automatiskt projektet och kör tester. Om tester misslyckas anses bygget vara trasigt och teamet åtgärdar problemet omedelbart. CI förhindrar situationen «det fungerar på min maskin» där en utvecklares kod bryter en annans kod.

Build Pipeline — en sekvens av steg som utförs vid varje push: kod-linting → enhetstester → debug APK/IPA-bygge → integrationstester → release-bygge. Varje steg körs endast efter att föregående steg har lyckats. Byggartefakter — APK, IPA, AAB, testrapporter — sparas och finns tillgängliga för nedladdning.

Continuous Delivery vs Continuous Deployment

Continuous Delivery — kod byggs och testas automatiskt, men en människa beslutar om lansering till produktion. Continuous Deployment — varje lyckat bygge lanseras automatiskt till produktion. För mobilappar är CD (leverans till butiker) via TestFlight eller Internal Testing vanligare, eftersom det slutgiltiga publiceringsbeslutet fattas av utvecklaren eller chefen. Staging — miljö så nära produktion som möjligt, som används för att testa bygget före lansering.

GitHub Actions och GitLab CI

GitHub Actions

GitHub Actions är ett inbyggt CI/CD-system för automatisering av mobilappar på GitHub. Actions använder YAML-konfiguration (.github/workflows) för att definiera pipelines. Färdiga actions finns tillgängliga för mobilutveckling: actions/setup-java, gradle-build-action för Android, xcodebuild-action för iOS. GitHub Actions erbjuder 2000 gratis minuter per månad för privata repositories.

Exempel: ett Android-arbetsflöde inkluderar kod-utcheckning, JDK 17-installation, cachning av Gradle-beroenden, körning av lint och enhetstester, APK-bygge och artefaktuppladdning. För iOS — utcheckning, Xcode-installation, pod install, XCTest-körning, arkivering och IPA-export. GitHub Actions integreras med GitHub Releases, Slack och Telegram för meddelanden.

GitLab CI

GitLab CI är ett inbyggt CI/CD-system i GitLab, konfigurerat via .gitlab-ci.yml. GitLab CI använder runners — agenter som utför jobb. För mobilutveckling kan du använda delade runners (Linux för Android) eller egna runners (macOS för iOS). GitLab CI stöder parallella jobb, artefakter, miljöer och manuellt godkännande för produktionslanseringar.

Bitrise för mobilappar

Varför Bitrise?

Bitrise är en CI/CD-plattform specialiserad på automatisering av mobilappar. Bitrise erbjuder färdiga Steps för Android, iOS, Flutter och React Native: Gradle Runner, Xcode Archive, Flutter Test, CocoaPods Install. Bitrise konfigurerar automatiskt kodsignering för iOS (via Codesigndoc) och tillhandahåller virtuella maskiner med förinstallerade Xcode, Android SDK, Flutter och andra verktyg.

Bitrise-fördelar: enkel installation via den visuella Workflow-redigeraren, stöd för parallella byggen, integration med Firebase Test Lab, App Store Connect och Google Play Console. Bitrise erbjuder 90 gratis minuter per månad för personliga projekt. På IT Sectr använder vi Bitrise för alla mobila projekt — det förenklar CI/CD avsevärt jämfört med manuell installation av GitHub Actions.

Fastlane: automatisering av mobila byggen

Vad är Fastlane?

Fastlane är ett automatiseringsverktyg för mobilappar för iOS och Android, skrivet i Ruby. Fastlane består av ett system med färdiga actions (200+) och ett DSL för att beskriva scenarier via Fastfile. Fastlane löser uppgifter som varje mobilutvecklare gör manuellt: kodsignering, skärmbildsgenerering, uppladdning till TestFlight och Google Play, hantering av certifikat och provisioning-profiler.

Viktiga Fastlane-komponenter

Lane — ett namngivet scenario i Fastfile. Exempel: lane :release do — en kedja av åtgärder för att lansera en version. Match — ett verktyg för säker lagring och synkronisering av certifikat och provisioning-profiler via ett krypterat Git-repository. Gym — bygga och arkivera iOS-appar (ett omslag runt xcodebuild). Pilot — uppladdning och hantering av byggen i TestFlight. Deliver — uppladdning av app och metadata till App Store Connect. Snapshot — automatisk skärmbildsgenerering på alla språk. Screengrab — automatisk skärmbildsgenerering för Android.

Exempel på Fastfile för Android: lane :beta anropar gradle (assembleRelease), sedan firebase_app_distribution för distribution till testare. För iOS: lane :beta anropar match (nedladdning av certifikat), gym (arkivering) och pilot (uppladdning till TestFlight). Fastlane kan köras lokalt och på en CI-server — vilket gör det till ett universellt verktyg i alla mobila projekt.

Canary Release och Feature Flags

Canary Release

Canary Release är en CI/CD-automatiseringsstrategi för att rulla ut en ny appversion till en liten andel användare (1–5 %) före den fullständiga lanseringen. I Google Play Console implementeras detta via Staged Rollout: du släpper en uppdatering till 5 % av din publik, övervakar krascher och mätvärden och ökar andelen om inga problem uppstår. I App Store Connect — via Phased Release for Automatic Updates.

A/B-testning — jämförelse av två versioner av en funktion på slumpmässiga användargrupper. Inom mobilutveckling utförs A/B-tester via Feature Flags, Firebase Remote Config eller serverlogik. Canary Release och A/B-tester minimerar riskerna vid utrullning av nya funktioner.

Feature Flags

Feature Flag (Feature Toggle) — villkorlig aktivering av funktionalitet utan att distribuera ny kod. En Feature Flag är en kontroll i koden: if (featureFlag.isEnabled()) { /* ny kod */ } else { /* gammal kod */ }. Flaggor hanteras via tjänster: LaunchDarkly, Split.io, Firebase Remote Config. Feature Flags tillåter utvecklare att slå samman kod till main även om funktionen ännu inte är redo för användare.

LaunchDarkly — den mest populära plattformen för hantering av Feature Flags. LaunchDarkly tillhandahåller SDK:er för iOS, Android, Flutter och React Native. Du kan aktivera funktioner för specifika användare, segment, regioner eller en andel av publiken. Feature Flags används också som kill switch — omedelbar inaktivering av en problematisk funktion utan att lansera en ny appversion.