Flutter CI/CD u 2026.: GitHub Actions vs Codemagic vs Fastlane (uz nacrt produkcijskog pipelinea)

# Što ovaj vodič pokriva#

Treba vam pipeline koji gradi, testira, potpisuje i isporučuje Flutter aplikacije bez “akrobacija” pri svakom izdanju. Ovaj vodič uspoređuje GitHub Actions, Codemagic i Fastlane u 2026., a zatim daje nacrt produkcijskog pipelinea koji pokriva flavors, generiranje koda, build brojeve, cacheiranje i deploy na oba storea.

Ciljana ključna riječ: Flutter CI/CD GitHub Actions Codemagic Fastlane.

Ako vam je važna i kvaliteta u runtimeu nakon isporuke, kombinirajte ovo s vodičem Flutter performance optimization for 60fps i produkcijskim slanjem poruka u Flutter push notifications with FCM and APNs. Za budžetiranje i planiranje tima pogledajte Flutter app development cost.

# CI/CD alati u 2026.: što zapravo znači “bitno”#

Mobilni CI/CD pada iz drugačijih razloga nego web CI. Balansirate težak toolchain, potpisivanje, ograničenja storeova i duga build vremena.

U praksi, odluku biste trebali optimizirati za ove ishode:

• Deterministički buildovi kroz različite strojeve i vrijeme.
• Brz feedback na PR-ovima, idealno ispod 10 minuta za testove i statičke provjere.
• Reproducibilno potpisivanje koje preživi promjene na developer laptopima.
• Sigurna izdanja sa staged rolloutima i mogućnošću audita.

Tri uloge: orkestrator, mobile build farma, automatizacija izdanja#

Ovi se alati preklapaju, ali razmišljanje po ulogama sprječava over-engineering:

• Orkestrator: odlučuje kada se jobovi pokreću, radi approvals, veže se uz PR-ove i brancheve. GitHub Actions je ovdje jak.
• Mobile build farma: daje macOS i Android okruženja sa smislenim defaultima, cacheiranjem i pomoćnicima za signing. Codemagic je ovdje jak.
• Automatizacija izdanja: komunicira s App Store Connect i Google Play, upravlja metapodacima, uploadom, rolloutom i release notes. Fastlane je i dalje “radni konj”.

🎯 Ključna poruka: Gledajte na GitHub Actions, Codemagic i Fastlane kao na slagive dijelove. Većina produkcijskih pipelinea koristi barem dva od njih, čak i ako je jedan primarni.

# GitHub Actions vs Codemagic vs Fastlane: praktična usporedba#

Ova tablica se fokusira na ono što se u stvarnim Flutter pipelineovima najčešće kvari: dostupnost macOS-a, potpisivanje, cacheiranje i ergonomija deploya na storeove.

Matrica preporuka prema veličini tima#

# Nacrt produkcijskog pipelinea: branching, flavors i okruženja#

Pouzdan pipeline počinje jasnim mapiranjem između Git branchova, flavors i store trackova.

Branch strategija koja funkcionira#

Česta strategija koja izbjegava release kaos:

• main za produkcijska izdanja.
• develop za integraciju i internu QA.
• release/* branchevi samo kad treba stabilizacija.
• Kratkoživući feature branchevi za PR-ove.

Mapirajte CI triggere na to:

• PR u develop: pokreni brze provjere.
• Push na develop: build i distribucija testerima.
• Tag na main: build i deploy na storeove.

Flavors i schemeovi#

Praktična postavka za Flutter aplikacije s više okruženja:

• dev flavor: interni endpointi, verbose logiranje, debug servisi uključeni.
• staging flavor: endpointi poput produkcije, release-mode buildovi za QA.
• prod flavor: produkcijski endpointi, stroge zastavice.

Na Androidu je to tipično productFlavors u Gradleu. Na iOS-u su to schemeovi vezani uz build konfiguracije.

ℹ️ Napomena: Držite bundle identifikatore različite po flavoru. Korištenje istog identifikatora za dev i prod stvara sudare u signing/provisioningu i otežava instalacije na uređaje.

Build brojevi: determinističko pravilo#

Odaberite pravilo build broja koje možete objasniti u jednoj rečenici. Dva česta pristupa:

• Monotoni CI run broj: jednostavno i uvijek raste, ali može varirati po branchovima.
• Temeljeno na timestampu: YYYYMMDDHHMM, deterministički, neovisan o branchu.

Robustan produkcijski izbor je:

• versionName iz Git taga, npr. 1.8.0.
• buildNumber iz CI run broja ili timestampa.

Za Flutter ga možete proslijediti kroz --build-name i --build-number.

# Faze pipelinea: što se pokreće gdje#

Produkcijski pipeline treba biti podijeljen u faze kako ne biste plaćali macOS build vrijeme za svaki PR.

Faza 1: PR provjere ispod 10 minuta#

Izvodite na Linux runnerima zbog cijene i brzine:

• flutter analyze
• unit testovi
• formatiranje i linting
• validacija generiranja koda

Ovdje hvatate većinu problema prije nego uopće dođete do signinga.

Faza 2: integracijski build za testere#

Pokrećite na macOS-u samo ako treba. Za Android-only distribuciju Linux je dovoljan.

Outputi:

• Android apk za brzi QA ili aab za Play Internal testing
• iOS ipa za TestFlight

Faza 3: release build i deploy na storeove#

Okida se tagom na main, uz manualne approval gateove.

Outputi:

• Upload na Play Store u Internal ili Production sa staged rolloutom.
• Upload na App Store Connect, zatim TestFlight ili App Store release.

# GitHub Actions: produkcijski workflow koji možete kopirati#

Ovaj workflow je namjerno podijeljen: PR provjere na Ubuntu, releaseovi na macOS-u.

Pregled GitHub Actions workflowa#

Primjer PR checks workflowa#

name: pr-checks
 
on:
  pull_request:
    branches: [develop, main]
 
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: "3.27.0"
          cache: true
      - run: flutter pub get
      - run: dart run build_runner build --delete-conflicting-outputs
      - run: flutter analyze
      - run: flutter test --coverage

Ovo sprječava klasični failure mode: generirane datoteke nisu commitane ili se ne regeneriraju u CI-ju.

⚠️ Upozorenje: Ako se oslanjate na to da su generirane datoteke commitane, vaš CI mora ili regenerirati i failati na diffovima, ili validirati da working tree ostaje čist. Inače se releaseovi mogu razlikovati od lokalnih buildova.

Release build brojevi i flavors#

Primjer komandi koje možete ponovno koristiti kroz providere:

flutter build appbundle \
  --flavor prod \
  --release \
  --build-name=1.8.0 \
  --build-number=2026050912

flutter build ipa \
  --flavor prod \
  --release \
  --build-name=1.8.0 \
  --build-number=2026050912

Cacheiranje koje pomaže bez kvarenja buildova#

Cache štedi minute, ali stale cache može isporučiti krivi kod. Cacheirajte:

• Flutter SDK, preko Flutter action cachea.
• Pub cache.
• Gradle cacheve.

Izbjegavajte cacheiranje:

• build outputa.
• iOS DerivedData preko nepovezanih branchova.

Pragmatično pravilo: cacheirajte ovisnosti, ne artefakte.

# Codemagic: kad želite manje održavanja#

Codemagic briljira kad želite pouzdan macOS, ugrađene signing workflowe i brzi setup za App Store Connect i Google Play.

Što Codemagic radi bolje za Flutter mobile#

• Opinionated koraci za Flutter verzije i Xcode.
• Lakši iOS signing setup za timove bez dedicated iOS inženjera.
• Jednostavno upravljanje environment varijablama za flavors.

Codemagic je često najbrži put do pipelinea koji stvarno deploya iOS, jer iOS CI padovi su obično oko provisioning/entitlements, ne oko samog Fluttera.

Codemagic pattern za pipeline#

Česta real-world Codemagic postavka:

• Workflow: pr_checks na Linuxu ili macOS-u ovisno o potrebama.
• Workflow: staging_distribute na push u develop, proizvodi TestFlight i Play Internal.
• Workflow: prod_release na tag, push na storeove.

Ako kasnije trebate više kontrole, i dalje možete pokretati Fastlane unutar Codemagica.

💡 Savjet: Ako ste mali tim, krenite s Codemagicom za iOS distribuciju, a Android držite na GitHub Actionsu. To smanjuje macOS minute i zadržava GitHub-native PR provjere.

# Fastlane u 2026.: i dalje okosnica izdanja#

Fastlane ostaje najbolji način za standardizaciju interakcije sa storeovima, posebno kad trebate:

• konzistentne release notes
• phased rolloute
• automatsko povećanje build brojeva
• jednu komandu za isporuku

Fastlane laneovi za Android i iOS#

Držite laneove jednostavnima: build radi Flutter, deploy radi Fastlane.

Android lane koristeći supply:

default_platform(:android)
 
platform :android do
  desc "Deploy AAB to Play Internal"
  lane :internal do
    upload_to_play_store(
      track: "internal",
      aab: "../build/app/outputs/bundle/prodRelease/app-prod-release.aab",
      skip_upload_metadata: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end
end

iOS lane koristeći pilot:

default_platform(:ios)
 
platform :ios do
  desc "Upload to TestFlight"
  lane :testflight do
    upload_to_testflight(
      ipa: "../build/ios/ipa/MyApp.ipa",
      skip_waiting_for_build_processing: true
    )
  end
end

Ovi laneovi pretpostavljaju da je CI već izgradio artefakte. Ovo razdvajanje olakšava debugiranje i sprječava da Fastlane postane vaš build sustav.

# Signing i tajne: dio koji najčešće puca#

Android signing: pattern uvoza keystorea#

Držite ovo u CI secret storeu:

• base64-enkodirani keystore
• lozinka keystorea
• alias ključa
• lozinka ključa

U CI-ju ga dekodirajte i upišite key.properties.

echo "$ANDROID_KEYSTORE_BASE64" | base64 --decode > android/app/upload-keystore.jks
 
cat > android/key.properties << 'EOF'
storePassword='"$ANDROID_KEYSTORE_PASSWORD"'
keyPassword='"$ANDROID_KEY_PASSWORD"'
keyAlias='"$ANDROID_KEY_ALIAS"'
storeFile=upload-keystore.jks
EOF

iOS signing: odaberite jedan od dva pristupa#

Ako koristite match, nemojte ga tretirati kao magiju. Vaš stvarni “source of truth” postaje match repozitorij plus Apple Developer portal.

⚠️ Upozorenje: Većina iOS CI padova nisu “Xcode problemi”. To su mismatchani bundle ID-evi, nedostajuće capabilityje, istekli certifikati ili pogrešni provisioning profili za odabrani scheme i flavor.

# Generiranje koda i lokalizacija: učinite to determinističkim#

Flutter projekti često uključuju:

• build_runner za JSON serijalizaciju ili DI
• generiranje lokalizacije
• API klijente iz OpenAPI-ja
• generiranje asseta

Release pipeline mora pokretati iste generatore kao lokalni razvoj. Ako commitate generirane datoteke, dodajte validacijski korak koji faila na diffu.

Jednostavan pattern:

1. 1
   Pokreni generatore.
2. 2
   Pokreni testove.
3. 3
   Provjeri da nema promjena.

dart run build_runner build --delete-conflicting-outputs
git diff --exit-code

Ovo hvata “drift” koji se inače manifestira kao bugovi tipa “radi kod mene”.

# Strategija testiranja koja se uklapa u CI budžet#

Ne morate pokretati sve na svaki push. Trebate prave testove u pravoj fazi.

Realističan cilj:

• PR provjere ispod 10 minuta.
• Noćni integration testovi samo za kritične tokove.

# Deploy na storeove: trackovi, rollout i sigurnost#

Google Play: Internal, Closed, Production#

Sigurna progresija:

• Internal track na svaki merge u develop.
• Closed track za release candidateove.
• Production samo na tagane releaseove, sa staged rolloutom.

Staged rollout postavite u CI-ju preko Fastlanea ili Play Developer API politika. Operativni dobitak je ogroman: možete stati na 5% rolloutu umjesto hotfixati na 100%.

App Store Connect: prvo TestFlight#

Za iOS, tretirajte TestFlight kao svoj “internal track”.

• Uploadajte svaki merge u develop na TestFlight ako tim testira na pravim uređajima.
• Promovirajte na App Store samo iz main tagova.

To smanjuje broj “ne možemo reproducirati” bugova jer su testeri uvijek na potpisanom, release-mode buildu.

# Preporučena postavka za male timove#

Malim timovima treba manje pokretnih dijelova i manje kredencijala za održavanje. Cilj je pipeline koji možete držati u pogonu bez dedicated DevOps headcounta.

Praktični default u 2026.#

• GitHub Actions za PR provjere na Linuxu.
• Codemagic za iOS buildove i TestFlight distribuciju.
• Fastlane samo ako trebate naprednu kontrolu rolloutea ili automatizaciju metapodataka.

Ovaj hibrid drži PR provjere blizu code reviewa, a najteži dio CI-ja prebacuje na upravljano macOS okruženje.

Minimalna mapa workflowa#

Ako preferirate jednu platformu: Codemagic može vrtjeti sve, ali gubite dio GitHub-native ergonomije za PR-ove.

# Česti failure modeovi i kako ih spriječiti#

1) Itekli iOS certifikati ili krivi provisioning profile#

Simptomi:

• Code signing error tijekom archivea.
• Provisioning profile ne uključuje potrebne capabilityje.

Prevencija:

• Koristite Fastlane match i rotirajte certifikate namjerno.
• Držite checklistu za nove capabilityje poput push notifikacija, associated domains, Sign in with Apple.
• Osigurajte da bundle ID specifičan za flavor odgovara provisioning profilu.

Ovo postaje kritično kod implementacije produkcijskih push tokova kao u Flutter push notifications with FCM and APNs, jer uključivanje APNs-a često mijenja entitlements i potrebne capabilityje.

2) Cacheiranje stvara stale ili nedosljedne buildove#

Simptomi:

• CI prolazi, ali se aplikacija ruši zbog zastarjelog generiranog koda.
• Nasumični build failurei nakon updatea ovisnosti.

Prevencija:

• Cacheirajte ovisnosti, ne build outpute.
• Keyajte cache po lockfile hash-u.
• Čistite cache na bump Flutter ili Xcode verzija.

3) Sudaranje build brojeva ili build broj ne raste#

Simptomi:

• App Store Connect odbija upload jer je build broj već korišten.
• Play Console pokazuje neočekivano verzioniranje.

Prevencija:

• Koristite deterministički izvor build broja po releaseu.
• Za iOS osigurajte da se build broj poveća čak i pri rebuildanju istog taga.

4) Mismatch flavor-a i schemea#

Simptomi:

• CI builda krivo okruženje, produkcijska aplikacija pokazuje prema staging API-ju.
• Krivi bundle ID uzrokuje signing failove.

Prevencija:

• Učinite flavor eksplicitnim u svakoj build komandi.
• Zahtijevajte CI varijable poput APP_ENV=prod i failajte ako nedostaju.
• Dodajte build-time asert koji logira okruženje i endpoint.

5) Nedostajući koraci generiranja koda#

Simptomi:

• Kompajliranje pada na CI-ju zbog nedostajućih datoteka.
• Runtime greške zbog zastarjelih serializer-a.

Prevencija:

• Pokrećite generatore u CI-ju i failajte na diff.
• Dokumentirajte generator komande u README-u repozitorija.
• Držite verzije generatora pinane u pubspec.lock za app repozitorije.

💡 Savjet: Dodajte “pipeline smoke test” koji se tjedno pokrene od nule s isključenim cacheovima. Hvata skrivene ovisnosti o cacheiranim artefaktima i sprječava neugodna iznenađenja na dan releasa.

# Očekivanja troška i vremena za CI/CD#

CI/CD je dio ukupnog troška aplikacije, ne “besplatan dodatak”. Timovi ga često podcijene do prvog hitnog izdanja.

Tipični rasponi koje viđamo u stvarnim projektima:

• Osnovni Android plus iOS CI sa signingom: 1 do 3 dana ako su zahtjevi jednostavni.
• Flavors, staging distribucije i deploy na storeove: 3 do 7 dana.
• Hardening, rolloute, integration testovi i audit logovi: 1 do 2 tjedna.

Ako planirate budžete, uključite CI/CD kao stavku jednako kao što uključujete analitiku i crash reporting. To se uklapa u šire pokretače troška o kojima se govori u Flutter app development cost.

# Ključne poruke#

• Podijelite pipeline na Linux PR provjere i macOS release jobove kako biste smanjili trošak i povećali brzinu.
• Učinite flavors eksplicitnima u svakoj CI build komandi i držite bundle identifikatore različitima po okruženju kako biste izbjegli signing sudare.
• Pokrećite generiranje koda u CI-ju i failajte na diffovima kako biste spriječili izdanja tipa “radi lokalno”.
• Cacheirajte ovisnosti, ne build outpute, i keyajte cache po lockfile hash-u kako biste izbjegli stale buildove.
• Za male timove hibrid je često najbolji: GitHub Actions za PR provjere, Codemagic za iOS distribuciju i Fastlane za naprednu automatizaciju storeova.

# Zaključak#

Produkcijski spreman Flutter CI/CD pipeline u 2026. manje je pitanje odabira jednog alata, a više slaganja odgovornosti: GitHub Actions za orkestraciju, Codemagic za pouzdane mobile buildove i Fastlane za zrele deployeve na storeove.

Ako želite da implementiramo ovaj nacrt za vašu aplikaciju, uključujući flavors, signing, staged rolloute i ojačan release proces, kontaktirajte Samioda. Postavit ćemo pipeline uz koji vaš tim može isporučivati s pouzdanjem, a zatim pomoći poboljšati runtime kvalitetu uz 60fps performance practices i produkcijsko slanje poruka putem FCM and APNs.