Continuous Integration (CI) — apa itu, prinsip dan pengaturan otomatisasi

Apa itu Continuous Integration

Continuous Integration (CI) — adalah metodologi pengembangan yang mengotomatiskan proses integrasi kode dari beberapa partisipan ke dalam satu basis kode. Istilah ini diperkenalkan oleh Martin Fowler pada awal tahun 2000-an sebagai seperangkat praktik yang mencegah “neraka integrasi” — situasi di mana pengembang bekerja secara terisolasi selama berminggu-minggu, dan saat menggabungkan perubahan muncul banyak konflik yang membutuhkan hari-hari penyelesaian manual.

Masalah yang dipecahkan CI

Tanpa CI, pengembang menyelesaikan fitur, mencoba menggabungkan perubahannya dengan cabang main dan menemukan bahwa rekan kerja telah mengubah file yang sama. Resolusi konflik memakan waktu berjam-jam dan sering merusak kode yang berfungsi. CI memecahkan masalah ini dengan integrasi paksa beberapa kali sehari: semakin sering integrasi, semakin sedikit konflik dan semakin mudah penyelesaiannya. Praktik menunjukkan bahwa dengan integrasi harian, resolusi konflik memakan waktu menit, sedangkan dengan integrasi mingguan — berjam-jam.

Efek ekonomi CI

Menurut IBM Systems Sciences Institute, biaya perbaikan bug pada tahap penulisan kode adalah $25, pada tahap pengujian — $100, pada tahap produksi — $2.500. CI menggeser deteksi cacat ke kiri (shift left), menemukan kesalahan pada tahap commit ketika perbaikannya hampir gratis. Tim dengan CI menghabiskan rata-rata 15% waktu untuk debugging dibandingkan 35% pada tim tanpa CI.

Prinsip Dasar Continuous Integration

Martin Fowler mendefinisikan praktik-praktik kunci CI yang tetap relevan terlepas dari tumpukan teknologi. Mengikuti prinsip-prinsip ini menjamin bahwa CI memberikan manfaat, bukan menjadi beban birokrasi. Pengembangan mobile menambahkan persyaratan tambahan, tetapi intinya tetap tidak berubah.

Repositori tunggal

Semua kode proyek disimpan dalam satu repositori dengan satu sistem kontrol versi (Git). Sumber kebenaran tunggal mengecualikan situasi di mana fitur dikembangkan dalam fork dan tidak disinkronkan dengan basis kode utama selama berminggu-minggu. Dalam proyek mobile, ini berarti bagian Android, iOS, dan backend dapat berada dalam satu repositori (monorepositori) atau dalam repositori terpisah dengan skema versi bersama.

Build otomatis

Build proyek harus dilakukan dengan satu perintah. Untuk Android adalah ./gradlew assembleDebug, untuk iOS — xcodebuild atau fastlane build. Skrip build memeriksa reprodusibilitas: build di server CI harus memberikan hasil yang sama seperti di mesin pengembang. Setiap perbedaan lingkungan dihilangkan dengan containerisasi atau IaC (Infrastructure as Code).

Pengujian otomatis

Setelah build, semua level pengujian dilakukan: modul, integrasi, dan UI. Jika pengujian gagal — commit dianggap tidak valid. Mempertahankan status hijau adalah tanggung jawab bersama tim. Dalam proyek mobile, sering dipisahkan pengujian cepat (dilakukan hingga 5 menit per commit) dan pengujian lambat (pengujian UI pada perangkat nyata, dijalankan lebih jarang).

// Contoh pengujian unit dengan laporan CI-friendly
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 dan transparansi

Hasil CI bersifat publik untuk seluruh tim: setiap orang melihat commit siapa yang merusak build. Transparansi menciptakan budaya tanggung jawab: pengembang memeriksa perubahan mereka sebelum push dan memperbaiki build yang rusak di luar antrian. Server CI mengirimkan notifikasi ke Slack atau Telegram saat status build berubah.

Komponen Sistem CI

Sistem CI yang lengkap terdiri dari beberapa komponen yang saling berinteraksi. Setiap komponen bertanggung jawab atas bagian pipanya sendiri: dari peluncuran hingga laporan. Memahami arsitektur CI membantu mendiagnosis masalah dan mengoptimalkan kinerja.

Server CI

Komponen pusat yang mengelola antrian build, distribusi sumber daya, dan publikasi hasil. Server CI bisa berbasis cloud (GitHub Actions, GitLab CI, CircleCI) atau self-hosted (Jenkins, TeamCity). Server melacak perubahan di repositori melalui webhook atau polling dan menjalankan pipeline pada setiap push atau pull request.

Runner dan agen

Runner adalah mesin virtual atau fisik yang menjalankan tugas build. Di CI cloud, runner disediakan oleh penyedia dan dibayar berdasarkan waktu penggunaan. Runner self-hosted dipasang di infrastruktur sendiri dan memerlukan pemeliharaan. Untuk build iOS diperlukan runner macOS, untuk Android — Linux atau Windows.

Artefak dan cache

Setelah build, sistem CI menyimpan artefak (APK, IPA, laporan pengujian) di penyimpanan — tersedia untuk diunduh dan di-deploy. Caching dependensi (Gradle cache, CocoaPods cache) antar proses mempercepat build berikutnya 3–5 kali lipat.

Continuous Integration untuk Aplikasi Mobile

Pengembangan mobile menuntut persyaratan khusus untuk CI, berbeda dari proyek web atau backend. Build yang lama (3–15 menit untuk Android, 5–20 menit untuk iOS), beberapa jenis artefak (APK, AAB, IPA), kebutuhan penandatanganan dan obfuskasi — semua ini memerlukan konfigurasi pipeline CI secara individual.

Pipeline CI Android

CI tipikal untuk Android meliputi: linting (ktlint, detekt) dan analisis statis, pengujian unit dengan JUnit dan MockK, build debug dan release APK/AAB, pengujian instrumental di emulator dalam CI dan publikasi artefak. Cache Gradle mempercepat build berulang — tanpanya setiap build mengunduh dependensi lagi, kehilangan 3–5 menit.

Pipeline CI iOS

CI iOS memerlukan runner macOS untuk kompilasi kode Swift/Objective-C. Pipeline meliputi: instalasi dependensi CocoaPods atau SPM, SwiftLint untuk pemeriksaan gaya, pengujian unit dengan XCTest, build IPA, penandatanganan sertifikat melalui Fastlane match dan upload ke TestFlight. Runner self-hosted di Mac mini atau Mac di pusat data — alternatif untuk runner cloud macOS.

Proyek cross-platform (Flutter, React Native)

Flutter dan React Native dikompilasi menjadi build native untuk kedua platform. CI harus mendukung dua runner: Linux untuk build Android dan macOS untuk build iOS. Strategi optimal — pipeline terpisah: build Android di runner Linux, build iOS di runner macOS, setelah itu kedua artefak digabungkan menjadi satu release.

Perbandingan Alat CI

Pemilihan alat CI tergantung pada ukuran tim, kinerja yang diperlukan, anggaran, dan tumpukan teknologi. Di bawah ini adalah perbandingan solusi populer dengan penekanan pada pengembangan mobile. Solusi self-hosted memberikan kontrol tetapi memerlukan administrasi, solusi cloud — kenyamanan tetapi membatasi konfigurasi.

GitHub Actions

Gratis untuk repositori publik (2000 menit/bulan). GitHub Actions menawarkan ekosistem action siap pakai untuk Android (gradle/actions) dan iOS (apple-actions). Minus — runner macOS hanya tersedia di paket berbayar. Ideal untuk Open Source dan tim kecil yang sudah menggunakan GitHub.

Jenkins

Server CI self-hosted dengan kode sumber terbuka. Jenkins dikonfigurasi melalui Groovy Pipeline, mendukung ratusan plugin dan bekerja di perangkat keras apa pun. Memerlukan insinyur DevOps untuk instalasi dan pemeliharaan. Populer di segmen enterprise di mana kontrol atas infrastruktur sangat penting.

GitLab CI

CI/CD terintegrasi di GitLab dengan arsitektur runner terbuka. GitLab CI memungkinkan penggunaan runner sendiri (termasuk macOS) di paket gratis. Konfigurasi YAML lebih kuat dari GitHub Actions tetapi lebih sulit dipelajari. Cocok untuk tim yang menggunakan GitLab sebagai platform DevOps tunggal.

CircleCI

CI cloud dengan penekanan pada kecepatan. CircleCI mendukung image Docker, macOS, dan Android, secara otomatis menyimpan cache dependensi. Harga berbasis kredit — lebih mahal dari GitHub Actions untuk tim kecil, tetapi lebih cepat berkat runner yang dioptimalkan. Direkomendasikan untuk proyek produksi dengan persyaratan kecepatan.

Contoh Konfigurasi CI

Mari kita lihat konfigurasi CI untuk proyek Android menggunakan GitHub Actions. Pipeline melakukan analisis statis, build, dan pengujian pada setiap push dan pull request ke cabang main. Konfigurasi minimal memakan waktu 15 menit dan tidak memerlukan layanan eksternal.

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/

Pipeline terdiri dari dua job paralel: lint (melakukan analisis statis) dan unit-tests (bergantung pada lint — jika linting gagal, pengujian tidak dijalankan). Job unit-tests mengunggah laporan pengujian sebagai artefak — tim dapat melihatnya di antarmuka GitHub Actions tanpa mengunduh file secara lokal.

Pemeriksaan lokal sebelum CI

Untuk menghindari kegagalan CI karena kesalahan sepele, konfigurasikan pre-push hook di Git atau tugas Gradle yang menjalankan pemeriksaan yang sama secara lokal. Contoh: ./gradlew ktlintCheck detekt testDebugUnitTest. Jika pemeriksaan lokal memakan waktu lebih dari 3 menit — bagi menjadi cepat (linter) dan lambat (pengujian), jalankan yang cepat sebelum setiap commit dan yang lambat hanya sebelum push.