Build Server dalam pengembangan mobile — apa itu, tugas dan prinsip kerja

Apa itu Build Server

Build Server (server kompilasi) — adalah sistem komputasi khusus yang dirancang untuk menjalankan tugas terkait kompilasi kode dan persiapan rilis secara otomatis. Tidak seperti kompilasi lokal di mesin pengembang, server bekerja dengan salinan repositori, menggunakan lingkungan yang bersih dan versi dependensi tetap.

Server build adalah komponen kunci dari praktik Continuous Integration. Ini memastikan bahwa setiap commit melewati proses verifikasi yang sama terlepas dari siapa yang melakukannya. Ini menghilangkan masalah “berfungsi di mesin saya” dan memastikan standar kualitas yang seragam.

Menurut data Google DORA, 2025, tim yang menggunakan server build khusus mengurangi waktu konfirmasi perubahan dari jam menjadi menit. Ini secara langsung mempengaruhi kecepatan pengiriman fitur dan perbaikan ke pengguna akhir.

Mengapa server build diperlukan dalam pengembangan mobile

Kompilasi aplikasi mobile membutuhkan sumber daya yang signifikan: kompilasi Kotlin atau Swift dapat memakan waktu 5 hingga 40 menit. Jika kompilasi dijalankan di mesin lokal pengembang, ia tidak dapat bekerja secara produktif sampai selesai. Server build memecahkan masalah ini dengan membebaskan pengembang untuk tugas lain.

Perbedaan antara server build dan server CI

Dalam praktiknya, istilah ini sering digunakan secara bergantian, tetapi ada perbedaan: server CI (Jenkins, CircleCI) — adalah sistem yang mengelola pipeline, sedangkan server build — adalah host fisik atau virtual tempat pipeline tersebut dijalankan. Satu server CI dapat mengelola banyak agen build (build slaves).

Arsitektur server build

Server build tipikal terdiri dari beberapa komponen, masing-masing bertanggung jawab untuk tahap tertentu dari proses. Memahami arsitektur membantu menskalakan infrastruktur dengan benar di bawah beban tim.

Komponen utama

Inti (executor) — menjalankan tugas build. Dapat berfungsi sebagai kontainer Docker, mesin virtual, atau langsung di host. Antrian tugas mengelola prioritas build paralel. Penyimpanan artefak menyimpan hasil (APK, IPA, AAB) untuk publikasi selanjutnya.

Jaringan agen build (build farm)

Untuk mempercepat kerja, server build dapat mengelola kumpulan agen. Setiap agen — adalah mesin atau kontainer terpisah yang mampu menjalankan build. Saat beban meningkat, penskalaan otomatis (auto-scaling) menambahkan agen baru di cloud. Misalnya, Jenkins dengan plugin Kubernetes dapat secara dinamis membuat pod untuk setiap build.

pipeline {
    agent {
        kubernetes {
            yaml """
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: android-sdk
    image: openjdk:17-jdk
    command: ['sleep','infinity']
"""
        }
    }
    stages {
        stage('Build') {
            steps {
                sh './gradlew assembleDebug'
            }
        }
    }
}

Jenis server build

Server build dibagi menjadi beberapa kategori berdasarkan metode hosting dan tumpukan teknologi target. Pemilihan solusi spesifik tergantung pada ukuran tim, anggaran, dan persyaratan keamanan.

Server build self-hosted

Jenkins, TeamCity, Bamboo, GitLab Runner (self-hosted) — diinstal di server sendiri atau VPS. Kelebihan: kontrol penuh atas konfigurasi, kemampuan menggunakan perangkat lunak apa pun, data tidak meninggalkan infrastruktur perusahaan. Kekurangan: biaya administrasi, pembaruan, dan penskalaan.

Solusi cloud terkelola

GitHub Actions, CircleCI, Bitrise, Codemagic, GitLab SaaS — tidak memerlukan manajemen server. Pembayaran dilakukan per menit build atau berdasarkan langganan. Untuk tim kecil, ini adalah awal yang optimal. Untuk proyek besar dengan volume build tinggi, biaya dapat melebihi harga solusi self-hosted.

Server build untuk pengembangan iOS

Kekhasan iOS adalah bahwa kompilasi hanya mungkin dilakukan di macOS. Opsi: Mac mini di rak, MacStadium (sewa Mac), GitHub Actions dengan macOS runner, Bitrise dengan agen Mac sendiri. Server build Mac self-hosted memerlukan pembelian peralatan mahal dan pemeliharaannya.

Cara mengatur server build

Mari kita lihat langkah demi langkah pengaturan server build untuk proyek mobile dengan build Android dan iOS. Sebagai dasar, kita menggunakan GitHub Actions dengan runner self-hosted untuk iOS dan runner cloud untuk Android.

Langkah 1: Instalasi dan konfigurasi server CI

Pilih platform manajemen (Jenkins, GitLab, GitHub Actions). Instal node master, konfigurasi akses ke repositori melalui SSH atau personal access token. Konfigurasi webhook untuk memulai build secara otomatis saat push ke repositori.

Langkah 2: Menambahkan agen build

Daftarkan satu atau lebih mesin sebagai agen (slaves/runners). Untuk build Android, agen dapat bekerja di Linux atau Windows dengan JDK, Android SDK, Gradle terinstal. Untuk iOS — di macOS dengan Xcode Command Line Tools dan CocoaPods.

Langkah 3: Konfigurasi pipeline

Tentukan tahapan: checkout, instalasi dependensi, build, pengujian, publikasi artefak. Untuk mempercepat, gunakan caching dependensi (Gradle cache, CocoaPods cache, Docker image layers).

name: Android Build
on:
  push:
    branches: [main, develop]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      - name: Cache Gradle
        uses: actions/cache@v4
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
      - name: Build Release APK
        run: ./gradlew assembleRelease
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-release.apk
          path: app/build/outputs/apk/release/app-release.apk

Perbandingan biaya server build

Pilihan antara server build self-hosted dan cloud bukan hanya keputusan teknis, tetapi juga keputusan finansial. Biaya sangat bervariasi tergantung pada volume build, waktu eksekusi yang diperlukan, dan kebutuhan macOS untuk iOS.

CAPEX vs OPEX

Server self-hosted memerlukan belanja modal (CAPEX): pembelian peralatan (Mac mini dari $699, rak server, peralatan jaringan), konfigurasi dan pemeliharaan. Solusi cloud — biaya operasional (OPEX): pembayaran per menit build. Untuk tim kecil, OPEX lebih menguntungkan, untuk proyek besar dengan ratusan build per hari, CAPEX terbayar dalam 6–12 bulan.

Biaya tersembunyi

Saat menghitung anggaran, perhitungkan biaya tersembunyi: waktu untuk pembaruan perangkat lunak, perbaikan kegagalan, pencadangan konfigurasi, penyimpanan artefak jaringan. Untuk solusi self-hosted, tambahkan 20–30% ke biaya pemeliharaan dasar. Untuk cloud — pastikan batas menit mencakup beban puncak, terutama sebelum rilis.

Optimasi biaya

Mengurangi biaya server build dapat dilakukan dengan beberapa cara: menggunakan instans spot di cloud (hingga 70% lebih murah), menyimpan cache dependensi antar build, membatasi waktu eksekusi pipeline yang gagal, dan mengonfigurasi penonaktifan otomatis agen self-hosted yang tidak aktif di luar jam kerja.

Praktik terbaik untuk server build

Kerja efektif server build memerlukan kepatuhan terhadap sejumlah prinsip. Optimalisasi kecepatan build dan stabilitas infrastruktur secara langsung mempengaruhi produktivitas tim pengembangan.

Caching dan build inkremental

Gradle Build Cache, CCache untuk C/C++, incremental compiler untuk Kotlin dan Swift — aktifkan semua mekanisme caching yang tersedia. Konfigurasi cache build jarak jauh (melalui HTTP atau S3) agar pengembang dan agen yang berbeda dapat berbagi hasil kompilasi.

Isolasi lingkungan

Setiap build harus dijalankan di lingkungan yang bersih. Gunakan kontainer Docker atau mesin virtual sementara untuk mengecualikan pengaruh build sebelumnya pada build saat ini. Ini menghilangkan masalah “kondisi kotor” (state pollution).

• Gunakan Docker untuk kontainerisasi lingkungan build — ini menjamin pengulangan build
• Siapkan monitoring server build — CPU, memori, disk, waktu build, frekuensi kesalahan
• Otomatiskan pembersihan artefak lama agar tidak memenuhi ruang disk

Keamanan server build

Server build memiliki akses ke kode sumber, kunci penandatanganan, dan rahasia. Minimalkan permukaan serangan: gunakan agen terisolasi untuk proyek yang berbeda, batasi akses ke node master, gunakan signed commits dan periksa dependensi untuk kerentanan.