Belajar Mobile Developer - CI/CD & Release Pipeline

#Pendahuluan

Setelah test suite siap di episode 16, saatnya mengotomasi seluruh proses: dari commit kode sampai aplikasi sampai di tangan pengguna. Di episode 17 ini kita bangun CI/CD & release pipeline — GitHub Actions untuk menjalankan build & test otomatis, Fastlane untuk orkestrasi build dan pengiriman ke store, serta build signing yang aman. Release manual yang menakutkan berubah menjadi proses yang bisa diulang tanpa error.

Mengapa pipeline penting? Karena release adalah momen paling berisiko dalam siklus pengembangan. Build yang tidak bisa direproduksi, keystore yang hilang, atau langkah manual yang terlupa — semuanya menghasilkan release yang rusak di tangan pengguna.

#CI/CD untuk Mobile

CI/CD mobile punya kekhasan: build sangat berat (Gradle/AGP, Xcode), butuh signing, dan distribusinya ke store (bukan sekadar deploy server). Pipeline sehat terdiri dari beberapa tahap:

100%

#GitHub Actions untuk Android

Contoh workflow yang menjalankan unit test + build debug di setiap push:

.github/workflows/android.yml

name: Android CI
on:
  push:
  pull_request:
 
jobs:
  test-and-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "17"
 
      - uses: gradle/actions/setup-gradle@v3
 
      - name: Run unit tests
        run: ./gradlew testDebugUnitTest
 
      - name: Build debug APK
        run: ./gradlew assembleDebug

Untuk Flutter/RN, langkahnya analog: install SDK → flutter test / npm test → build. Kunci CI: reproducible — semua dependensi dipin dengan lockfile (bun.lock, package-lock.json, pubspec.lock).

#Fastlane

Fastlane mengorkestrasi build + submission. Satu perintah (fastlane beta) menjalankan serangkaian lane:

fastlane/Fastfile

lane :beta do
  # Android
  gradle(task: "assembleRelease")
  supply(apk_paths: "app/build/outputs/apk/release/app-release.apk")
 
  # atau iOS
  # build_app(scheme: "Fitku")
  # upload_to_testflight(skip_waiting_for_build_processing: true)
end
 
lane :release do
  ensure_git_status_clean
  bump_build_number
  beta
  git_tag_push
end

Fastlane juga menangani screenshot otomatis (Snapfile) dan metadata store via deliver/supply.

Tip

Fastlane paling kuat saat dipanggil dari CI: pipeline memicu fastlane beta, yang menandatangani, membangun, dan meng-upload sekaligus. Setiap release jadi satu artefak yang sama dengan yang sudah diuji di CI — tidak ada lagi "release build lokal yang tidak bisa direproduksi".

#Build Signing

Aplikasi harus ditandatangani sebelum dipasang/distribusi. Di Android, keystore di-generate sekali dan disimpan rahasia (jangan pernah commit!). Pengaturan signing di build.gradle.kts membaca dari environment:

build.gradle.kts: signing dari env

signingConfigs {
    create("release") {
        storeFile = file(System.getenv("KEYSTORE_FILE") ?: "release.keystore")
        storePassword = System.getenv("KEYSTORE_PASSWORD")
        keyAlias = System.getenv("KEY_ALIAS")
        keyPassword = System.getenv("KEY_PASSWORD")
    }
}
 
buildTypes {
    getByName("release") {
        signingConfig = signingConfigs.getByName("release")
        isMinifyEnabled = true
    }
}

Di CI, secret ditaruh di GitHub Secrets dan di-inject ke env saat step signing. iOS analog: Provisioning Profile + certificate disimpan di GitHub Secrets / Fastlane match.

Caution

Keystore hilang = tidak bisa update aplikasi lagi (Android) — tidak ada cara legal untuk mengganti keystore tanpa publikasi ulang sebagai app baru. Backup keystore di tempat aman (password manager perusahaan, secure Vault), dan konfigurasikan rotasi lewat Play App Signing agar Google memegang kunci upload yang bisa diganti.

#Versioning & Distribusi

Gunakan Semantic Versioning: MAJOR.MINOR.PATCH + versionCode (Android, harus monoton naik).

Pola versioning

2.4.0 (build 340)   → rilis fitur minor
2.4.1 (build 341)   → hotfix patch
3.0.0 (build 350)   → breaking change
 
Android: versionName "2.4.1" + versionCode 341
iOS:    CFBundleShortVersionString "2.4.1" + CFBundleVersion 341

Saluran distribusi umum: Internal/Alpha (tim), Beta (penguji eksternal), Production (publik). Ini memungkinkan gradual rollout — timpa bug yang terlewat sebelum semua pengguna terdampak.

#Common Pitfalls CI/CD

Build di mesin lokal, bukan CI: artefak rilis harus lahir dari pipeline yang sama dengan hasil tes.
Secret di repository: keystore/password commit = kebocoran. Selalu GitHub Secrets + jangan pernah log.
Build yang lambat tanpa caching: Gradle cache, dependency cache, dan artefak antara wajib di-cache CI.
Meng-upload rilis tanpa test e2e kritis: minimal jalankan smoke test alur utama sebelum rollout.
Rollout penuh sekaligus: mulailah dengan persentase kecil untuk memantau crash (episode 19).

Note

Untuk Expo/RN, EAS Build & EAS Submit adalah alternatif terkelola yang sangat disarankan — cloud build + submit store tanpa server CI sendiri. Flutter punya Codemagic dan Fastlane; pilih yang paling cocok dengan tim kalian.

#Penutup

Pada episode 17 ini, kalian telah membangun pipeline rilis:

GitHub Actions menjalankan lint, test, dan build di setiap push.
Fastlane mengorkestrasi build, signing, dan submission store.
Build signing yang aman lewat env/CI secrets + Play App Signing.
Semantic versioning dan distribusi bertahap (alpha → beta → production).

Di episode 18 selanjutnya kita menembus gerbang terakhir: App Store & Play Store Publishing — proses submission, review guidelines, dan App Signing agar Fitku diterima dan dirilis. Sampai jumpa!