CI/CD Pipeline — apa itu, tahapan otomatisasi dan alat

Apa itu CI/CD Pipeline

CI/CD Pipeline — adalah kumpulan proses formal dan otomatis yang dilalui kode dari saat perubahan dikomit di repositori hingga penerapan ke produksi. Istilah ini menggabungkan dua praktik: Continuous Integration (integrasi berkelanjutan) dan Continuous Delivery (pengiriman berkelanjutan), yang bersama-sama membentuk jalur pengiriman perangkat lunak.

Sejarah munculnya CI/CD

Konsep Continuous Integration dijelaskan oleh Grady Booch pada tahun 1991 dan dipopulerkan oleh Martin Fowler pada tahun 2000-an. Continuous Delivery sebagai istilah menguat setelah buku Jez Humble dan David Farley “Continuous Delivery” (2010). CI/CD Pipeline modern menjadi standar de facto dalam pengembangan aplikasi mobile setelah tahun 2015 — dengan munculnya server CI cloud dan otomatisasi toko aplikasi.

Mengapa CI/CD Pipeline diperlukan dalam pengembangan aplikasi mobile

Aplikasi mobile memiliki persyaratan khusus untuk pembangunan dan publikasi: penandatanganan dengan sertifikat, beberapa konfigurasi (debug, release, staging), obfuskasi ProGuard/R8, beberapa jenis build (APK, AAB, IPA) dan integrasi dengan toko aplikasi. Melakukan langkah-langkah ini secara manual memakan waktu berjam-jam dan rentan terhadap kesalahan — CI/CD Pipeline mengotomatiskan rutinitas.

Tahapan CI/CD Pipeline untuk aplikasi mobile

CI/CD Pipeline standar untuk aplikasi Android atau iOS terdiri dari tujuh tahapan kunci. Beberapa tahapan dijalankan secara paralel, yang lainnya secara berurutan. Komposisi pasti tahapan tergantung pada tumpukan teknologi dan kematangan tim, tetapi intinya tetap tidak berubah.

1. Checkout dan instalasi dependensi

Jalur dimulai dengan mengkloning repositori dan menginstal dependensi: Gradle/Maven untuk Android, CocoaPods atau SPM untuk iOS. Caching dependensi di antara proses menjalankan mengurangi waktu instalasi dari 3–5 menit menjadi beberapa detik — optimasi ini didukung oleh semua layanan CI modern.

2. Analisis statis dan linting

Sebelum pembangunan, kode diperiksa oleh linter (ktlint, detekt untuk Android, SwiftLint untuk iOS) dan penganalisis statis (Android Lint, SonarQube). Linting mendeteksi potensi bug, pelanggaran gaya kode dan API usang sebelum menjalankan pengujian — prinsip fail-fast menghemat waktu tim.

3. Pembangunan proyek

Pada tahap pembangunan, seluruh proyek dikompilasi dan artefak dihasilkan: APK dan AAB untuk Android, IPA untuk iOS. Untuk Android digunakan tugas Gradle (assembleDebug, bundleRelease), untuk iOS — xcodebuild atau xcrun. Pembangunan dilakukan di lingkungan terisolasi server CI, yang menjamin reprodusibilitas.

# Contoh CI/CD Pipeline untuk Android di GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    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@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Pengujian otomatis

Setelah pembangunan, pengujian unit, pengujian integrasi dan pengujian UI dijalankan. JUnit dan MockK untuk pengujian modular, Espresso dan Compose Test untuk UI di Android, XCTest dan XCUITest di iOS. Hasil dipublikasikan dalam laporan dan memblokir jalur jika pengujian kritis gagal.

5. Penandatanganan dan obfuskasi

Untuk build rilis, dilakukan penandatanganan dengan sertifikat digital (APK Signer untuk Android, codesign untuk iOS) dan obfuskasi kode. ProGuard atau R8 untuk Android mengurangi ukuran APK sebesar 15–30%. Kunci penandatanganan disimpan di rahasia server CI — tidak pernah dikomit ke repositori.

6. Pengiriman dan penerapan

Tahap akhir jalur — publikasi artefak: mengunggah APK ke pengujian internal Google Play Console, mengirim IPA ke TestFlight atau publikasi di Firebase Distribution. Continuous Delivery berarti langkah ini memerlukan konfirmasi manual, sementara Continuous Deployment dilakukan secara otomatis.

7. Pemberitahuan dan laporan

Setelah jalur selesai, tim menerima pemberitahuan dengan hasil: sukses/gagal, waktu eksekusi, tautan ke artefak. Slack, Telegram atau email — saluran pemberitahuan dipilih sesuai kebutuhan tim. Jika tahap gagal, tautan ke log kesalahan spesifik disertakan dalam pemberitahuan.

Apa perbedaan CI dan CD

Istilah CI dan CD sering digunakan sebagai satu konsep CI/CD, tetapi ada perbedaan mendasar di antara keduanya. CI (Continuous Integration) bertanggung jawab untuk pemeriksaan kualitas pada setiap integrasi kode, sementara CD (Continuous Delivery) memastikan kesiapan kode ini untuk rilis. Memahami perbedaan sangat penting saat merancang jalur.

Continuous Integration — pemeriksaan kualitas

CI dijalankan pada setiap push atau pull request dan mencakup pembangunan, analisis statis dan pengujian. Tujuan CI — mendeteksi masalah sedini mungkin, ketika biaya perbaikannya minimal. Jika CI tidak lulus — kode tidak masuk ke cabang utama. Rata-rata waktu eksekusi CI untuk proyek mobile adalah 5–15 menit.

Continuous Delivery — kesiapan untuk rilis

CD menambahkan ke CI tahapan persiapan rilis: penandatanganan, obfuskasi, pembuatan catatan rilis, pemeriksaan lisensi, publikasi di penyimpanan untuk penguji. CD menjamin bahwa setiap komit di cabang utama dapat diterapkan ke produksi dengan satu klik, tetapi rilis itu sendiri memerlukan persetujuan manual.

Alat untuk membangun CI/CD Pipeline

Ekosistem alat CI/CD untuk pengembangan aplikasi mobile mencakup layanan cloud, solusi self-hosted dan platform khusus. Pemilihan alat tergantung pada ukuran tim, anggaran dan persyaratan keamanan. Di bawah ini disajikan opsi paling populer.

GitHub Actions

CI/CD bawaan di GitHub dengan batas gratis 2000 menit per bulan untuk repositori publik. GitHub Actions populer berkat ekosistem besar action siap pakai (marketplace), kemudahan konfigurasi melalui YAML dan integrasi mulus dengan repositori GitHub. Keterbatasan — tidak ada dukungan runner Windows untuk build iOS di paket gratis.

GitLab CI/CD

Solusi self-hosted dan cloud dengan konfigurator YAML yang kuat. GitLab CI mendukung job paralel, caching, artefak dan lingkungan (environments). Populer di segmen enterprise karena kemungkinan penerapan di infrastruktur sendiri dan kontrol penuh atas data.

Jenkins

Server CI klasik dengan sumber terbuka. Jenkins dikonfigurasi melalui plugin (lebih dari 1800), mendukung Declarative Pipeline dalam format Groovy dan bekerja di lingkungan apa pun: Windows, macOS, Linux. Membutuhkan administrasi khusus, tetapi memberikan fleksibilitas konfigurasi maksimal.

CircleCI

Layanan CI cloud dengan penekanan pada kecepatan dan kesederhanaan. CircleCI secara otomatis menyimpan cache dependensi, mendukung gambar Docker untuk build terisolasi dan integrasi dengan macOS untuk build iOS. Penetapan harga berdasarkan jumlah kredit — cocok untuk tim yang menghargai kinerja.

Contoh konfigurasi CI/CD Pipeline

Mari kita lihat CI/CD Pipeline lengkap untuk aplikasi iOS menggunakan GitHub Actions dan Fastlane. Fastlane adalah alat otomatisasi untuk proyek mobile yang mengabstraksi operasi kompleks pembangunan, penandatanganan dan publikasi menjadi perintah sederhana.

# Fastfile — konfigurasi Fastlane untuk iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Menjalankan tes dan linting"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Membangun rilis dan mengunggah ke TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match mengelola sertifikat dan provisioning profiles, build_app membangun IPA, pilot mengunggah build ke TestFlight. Perintah fastlane release menjalankan semua tahapan secara berurutan: mengambil sertifikat, membangun, menandatangani, mengunggah ke App Store Connect untuk penguji beta.

CI/CD Pipeline untuk iOS dengan GitHub Actions

Integrasi Fastlane dengan GitHub Actions memungkinkan menjalankan jalur lengkap secara otomatis saat pull request ke cabang main. Self-hosted runner di macOS diperlukan untuk mengompilasi kode iOS — GitHub tidak menyediakan runner macOS di paket gratis.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

Praktik terbaik CI/CD Pipeline

Membangun CI/CD Pipeline yang efektif tidak hanya memerlukan pemilihan alat, tetapi juga mengikuti praktik yang terbukti. Tanpa organisasi yang tepat, jalur dapat menjadi hambatan yang memperlambat pengembangan alih-alih mempercepatnya. Di bawah ini — rekomendasi utama berdasarkan pengalaman tim mobile yang matang.

Fail fast

Pemeriksaan tercepat (linting, pengujian unit) dilakukan terlebih dahulu. Jika gagal — jalur berakhir tanpa menjalankan pengujian UI panjang atau pembangunan rilis. Fail fast menghemat menit waktu CI dan mempercepat umpan balik ke pengembang. Rata-rata waktu hingga kegagalan pertama tidak boleh melebihi 2–3 menit.

Caching dependensi

Cache Gradle, cache CocoaPods dan cache SPM harus dipulihkan di antara proses menjalankan. GitHub Actions mendukung caching melalui actions/cache, GitLab CI — melalui kata kunci cache. Tanpa caching, setiap build mengunduh semua dependensi dari awal — ini menambah 3–10 menit ke waktu jalur.

Eksekusi paralel

Tahapan independen (linter untuk Android dan iOS, pengujian unit modul berbeda) dijalankan sebagai job paralel. Paralelisasi mengurangi total waktu jalur dari 20–30 menit menjadi 5–10 menit. Sebagian besar layanan CI menghitung job paralel secara terpisah — pertimbangkan ini saat memilih paket tarif.

Isolasi lingkungan

Setiap proses menjalankan jalur dilakukan di lingkungan bersih: kontainer Docker, mesin virtual atau runner sementara. Isolasi mencegah pengaruh build sebelumnya pada build saat ini. Hindari penggunaan runner bersama antar proyek — kontaminasi lingkungan antar proyek menyebabkan kegagalan non-deterministik.

Keamanan rahasia

Kunci API, sertifikat penandatanganan dan token akses ke toko aplikasi disimpan di penyimpanan terenkripsi server CI. Jangan pernah menyertakan rahasia dalam log, artefak atau variabel lingkungan tanpa awalan SECRET_. Gunakan alat seperti Fastlane match untuk mengelola sertifikat iOS.