GitLab CI: esensi, pipeline dan integrasi berkelanjutan

Apa itu GitLab CI?

GitLab CI adalah bagian dari aplikasi DevSecOps terpadu GitLab yang mencakup integrasi berkelanjutan, pengiriman, dan penerapan. Sistem ini muncul pada tahun 2012 sebagai proyek terpisah, tetapi kemudian diintegrasikan langsung ke GitLab. Prinsip dasarnya — konfigurasi sebagai kode (Configuration as Code) melalui file .gitlab-ci.yml di root repositori. GitLab CI tersedia baik dalam versi cloud SaaS maupun instalasi self-managed.

Untuk pengembangan mobile, GitLab CI menawarkan otomatisasi pembangunan APK dan IPA, menjalankan pengujian instrumental, analisis kode statis, penandatanganan aplikasi, dan publikasi ke toko. Platform mendukung gambar Docker untuk lingkungan kustom, yang memungkinkan pra-instalasi Android SDK, NDK, Xcode, dan alat lainnya. Container Registry bawaan menyederhanakan penyimpanan dan distribusi gambar dalam tim.

Arsitektur GitLab CI: Runner, Pipeline dan Stage

Arsitektur GitLab CI terdiri dari tiga komponen utama. GitLab Runner adalah agen yang menjalankan job. Runner dapat berupa shared (disediakan oleh GitLab), group (untuk grup proyek), dan specific (untuk satu proyek). Setiap runner mendaftar dengan menentukan executor: Shell, Docker, Kubernetes, atau VirtualBox. GitLab Runner mendukung penskalaan otomatis (auto-scaling) untuk menangani beban puncak.

Pipeline adalah kumpulan stage yang dijalankan secara berurutan. Dalam satu stage, job dijalankan secara paralel. Struktur tipikal untuk proyek mobile: build → test → deploy. Jika job pada stage test berakhir dengan kesalahan, deploy tidak dijalankan. Pengaktifan manual (when: manual) dapat dikonfigurasi untuk penerapan. Juga didukung pemicu multi-project pipelines untuk skenario CI/CD kompleks antar repositori.

Executor GitLab Runner

Docker executor adalah yang paling populer untuk CI/CD aplikasi mobile. Setiap job dijalankan dalam kontainer Docker bersih, yang menjamin isolasi dan reprodusibilitas. Untuk pembangunan Android, digunakan gambar android-sdk dengan SDK terinstal, untuk iOS — runner macOS dengan executor Shell.

Konfigurasi .gitlab-ci.yml untuk Proyek Mobile

File .gitlab-ci.yml mendefinisikan pipeline dalam format YAML. Bagian utama: image (gambar Docker), stages (daftar tahap), variables (variabel lingkungan), before_script (perintah sebelum setiap job) dan job itu sendiri dengan bagian script, artifacts, cache. GitLab CI mendukung include — menghubungkan file YAML eksternal untuk penggunaan kembali konfigurasi bersama antar proyek.

Variables di GitLab CI dapat diatur di beberapa tingkat: global di UI, di file konfigurasi, di pengaturan grup dan proyek. Prioritas variabel ditentukan oleh hierarki: trigger variables memiliki prioritas tertinggi, kemudian CI/CD variables dari UI, kemudian dari .gitlab-ci.yml. Variabel dapat dilindungi (protected), membuatnya hanya dapat diakses untuk branch dan tag yang dilindungi.

Variabel dasar dan gambar

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Job pembangunan dengan artefak

Job generate-apk membangun proyek Gradle dan menyimpan APK sebagai artefak. Artefak ditransfer antar stage — job deploy dapat menggunakan APK dari build. Masa penyimpanan artefak dikonfigurasi melalui expire_in.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions: Perbedaan Utama

Saat memilih antara GitLab CI dan GitHub Actions untuk proyek mobile, penting untuk mempertimbangkan infrastruktur tim. GitLab CI menyediakan Container Registry bawaan yang dapat digunakan untuk menyimpan gambar Docker dengan Android SDK. GitHub Actions bergantung pada GitHub Packages atau registry eksternal. GitLab juga memiliki SAST bawaan (Pengujian Keamanan Aplikasi Statis) untuk analisis kode terhadap kerentanan.

GitLab CI menawarkan model runner yang lebih fleksibel — mendukung executor Kubernetes, penskalaan otomatis, dan gambar kustom. GitHub Actions unggul dalam integrasi dengan ekosistem GitHub dan pasar actions. GitLab CI memerlukan konfigurasi manual untuk banyak tugas yang di GitHub Actions diselesaikan dengan action siap pakai.

Dari perspektif CI/CD untuk proyek mobile: GitLab CI lebih cocok untuk perusahaan yang sudah menggunakan GitLab Self-Managed dan memerlukan runner self-hosted dengan Docker/Kubernetes. GitHub Actions lebih nyaman untuk tim kecil di GitHub cloud yang menghargai action siap pakai dan kemudahan konfigurasi.

Perbandingan kemampuan

Contoh Pipeline untuk Proyek Android

Pipeline lengkap untuk Android meliputi: lint, pengujian unit, pembangunan, dan penerapan di Firebase App Distribution. Pipeline menggunakan gambar Docker dengan Android SDK, cache Gradle, dan eksekusi paralel lint serta pengujian dalam satu stage. Pendekatan ini mengurangi total waktu pipeline, karena tugas lint dan test tidak saling bergantung.

Untuk proyek iOS, struktur pipeline berbeda karena kebutuhan runner macOS dan penandatanganan kode. Pipeline iOS tipikal meliputi: instalasi CocoaPods atau SPM, menjalankan pengujian pada simulator, pengarsipan proyek Xcode, ekspor IPA, dan unggah ke TestFlight. GitLab CI untuk iOS menggunakan runner macOS — baik runner GitLab SaaS macOS dengan batasan waktu, atau runner self-hosted di Mac mini atau MacStadium.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

Optimasi Waktu Pembangunan di GitLab CI

Optimalisasi pipeline pembangunan mobile di GitLab CI memerlukan perhatian pada detail. Konfigurasi yang benar dari cache dan artifacts memungkinkan pengurangan waktu pembangunan beberapa kali lipat. Untuk analisis kinerja, GitLab menyediakan CI/CD Analytics — dasbor dengan metrik durasi pipeline, beban runner, dan hambatan. Analisis metrik ini secara teratur untuk menemukan peluang optimalisasi. Pengaturan resource_group memblokir eksekusi paralel satu pipeline — berguna untuk mencegah konflik saat penerapan.

Strategi branch untuk CI juga penting. Disarankan menjalankan pipeline penuh hanya untuk branch main dan release, dan untuk branch fitur — hanya lint dan pengujian unit. Ini menghemat menit runner dan mempercepat umpan balik kepada pengembang. GitLab CI mendukung workflow:rules — aturan bersyarat untuk memasukkan atau mengecualikan job tergantung pada branch, file yang diubah, atau variabel lingkungan.

Caching dependensi adalah cara utama percepatan. GitLab CI menyimpan cache .gradle, Pods, dan node_modules antar eksekusi. Kunci cache mencakup $CI_COMMIT_REF_SLUG atau hash file lock. Waktu pembangunan proyek Android berkurang dari 10–15 menjadi 2–4 menit dengan caching yang tepat. Cache dapat didistribusikan — GitLab mendukung cache:key dengan fallback ke kunci sebelumnya.

Gambar Docker dengan alat pra-instal menghemat waktu instalasi. Disarankan membuat gambar kustom dengan Android SDK, NDK, dan level API yang diperlukan. Eksekusi paralel job (lint, test, assemble) di stage berbeda mengurangi total waktu pipeline. Pull policies untuk gambar (if-not-present) mempercepat memulai job. Juga dapat menggunakan dependency proxy untuk caching gambar di tingkat instance GitLab.

Aspek penting lainnya dari optimalisasi adalah penggunaan artefak antar tahap. File berat APK dan IPA lebih baik ditransfer melalui dependency daripada dibangun ulang di setiap job. Untuk proyek besar dengan puluhan modul, disarankan mengaktifkan Gradle Build Cache di tingkat pipeline dan mengonfigurasi cache remote di penyimpanan bersama. Timeout untuk setiap job harus diatur berdasarkan perkiraan waktu pembangunan — ini mencegah proses yang menggantung.

Contoh dengan caching dan pull policy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present