Panduan GCP Cloud Build: Otomasi CI/CD Serverless & Deployment Praktis

  

Pernah ngerasa capek ngurusin instance Jenkins yang sering crash pas CPU spikes gara-gara tim dev barengan nge-push code? Atau males bayar VM runner CI/CD yang nyala 24/7 padahal cuma kepakai pas jam kerja?

Di sinilah Google Cloud Build masuk ke stack infrastruktur lu. Layanan CI/CD managed dari GCP ini ngusung filosofi serverless: lu cuma bayar per detik pas proses build jalan, tanpa perlu mikirin patching OS, ngurus plugin usang, atau atur autoscaling runner.

💡 Analogi Gampangnya:

Ibarat lu mau bikin acara makan-makan. Lu gak perlu ngebangun restoran sendiri, beli peralatan dapur mahal, dan bayar koki 24/7 padahal acaranya cuma seminggu sekali (kayak Jenkins VM). Pakai Cloud Build itu kayak lu sewa koki panggilan + dapur profesional per menit. Pas ada orderan (push code), koki datang, masak (build), lalu dapurnya dibersihkan dan ditutup. Lu cuma bayar durasi koki masak doang.

Arsitektur Utama Cloud Build

Sebelum masuk ke teknis eksekusi, penting buat paham komponen utama yang menyusun arsitektur Cloud Build di ekosistem GCP:

1. Trigger Engine & Source Repositories

Pintu masuk utama Cloud Build. Ketika ada event (seperti git push, PR merged, atau pemicu via API/Pub-Sub), trigger engine bakal mengambil kode sumber dari repositori terhubung dan memicu pipeline.

2. Control Plane & Security Layer

Bagian ini mengatur autentikasi, izin IAM, serta pengelolaan variabel. Cloud Build mengeksekusi pipeline menggunakan Identity & Access Management (IAM) Service Account bawaan atau kustom, sehingga lu gak perlu nyimpan credential GCP di dalam repositori kode.

3. Execution Environment (Worker Pools)

Tempat di mana proses kompilasi dan pengujian berlangsung. GCP menyediakan dua opsi worker pool:

• Default Hosted Pool: Lingkungan multi-tenant yang sepenuhnya dikelola Google dengan akses internet publik. Sangat pas buat aplikasi umum yang tidak butuh koneksi ke jaringan internal private.

• Private Pools: Worker terisolasi (single-tenant) yang dipasang di VPC internal lu lewat VPC Peering. Cocok buat enterprise yang butuh nge-build aplikasi sambil mengakses database internal, private registry, atau cluster GKE tanpa floating IP publik.

💡 Analogi Worker Pools:

Default Pool itu kayak food court umum—siapa saja bisa masuk dan fasilitasnya terhubung ke jalan umum (internet publik). Sedangkan Private Pool itu kayak dapur khusus di dalam area gedung perkantoran VIP—hanya bisa diakses via pintu rahasia/koridor internal perusahaan (VPC Peering), tanpa pernah menyentuh jalan raya umum.

4. Shared Workspace & Storage

Selama proses build berlangsung, Cloud Build menyediakan ephemeral volume yang terpasang di direktori /workspace. Semua step di dalam pipeline berbagi volume ini untuk mentransfer file hasil kompilasi dari satu container ke container berikutnya.

💡 Analogi Shared Workspace (/workspace):

Bayangkan sebuah ban berjalan (conveyor belt) di pabrik perakitan mobil. Di stasiun 1 (Step 1 Container), mesin dirakit dan ditaruh di atas ban berjalan (/workspace). Saat ban bergerak ke stasiun 2 (Step 2 Container), teknisi kedua bisa mengambil mesin tersebut untuk dipasang ke rangka mobil. File hasil kompilasi tidak hilang antar-step karena selalu berada di atas "ban berjalan" yang sama.

Gimana Cara Kerja Cloud Build di Balik Layar?

Konsep dasar Cloud Build itu simpel banget: Everything is a Docker Container.

Secara teknis, setiap step yang lu tulis di dalam konfigurasi cloudbuild.yaml sebenarnya adalah eksekusi perintah command-line Linux di dalam kontainer Docker terisolasi (ephemeral).

Berikut anatomi eksekusi dari tiap step:

• name: Menentukan Docker image mana yang di-pull dari registry sebagai runner (contoh: golang:1.22, ubuntu, atau gcr.io/cloud-builders/gcloud).

• entrypoint / args / script: Menentukan command-line Linux atau script yang mau dijalankan di dalam kontainer tersebut.

• /workspace (Shared Volume): Setiap kontainer step otomatis me-mount direktori /workspace. Jadi kalau step 1 membuat file biner, step 2 di dalam kontainer yang berbeda bisa membaca file tersebut tanpa hilang.

Alurnya kira-kira gini:

1. Trigger Engine: Ada event masuk, misalnya git push ke branch main, pull request di GitHub/GitLab, atau pemicu manual dari Webhook.

2. Fetch Source: Cloud Build menduplikasi (checkout) repository lu ke dalam shared workspace (/workspace).

3. Step Execution: Cloud Build membaca berkas cloudbuild.yaml. Step 1 jalan via CLI di Kontainer A $\rightarrow$ hasil artifact disimpan di /workspace $\rightarrow$ Step 2 dibaca dan dieksekusi via CLI di Kontainer B $\rightarrow$ dst.

4. Publish & Deploy: Output berupa Docker image dikirim ke Artifact Registry, lalu dipicu buat deploy ke runtime target kayak Cloud Run, GKE, atau App Engine.

5. Clean Up: Lingkungan runner langsung dimusnahkan. Gak ada sampah sisa kompilasi yang nempel di server.

Anatomi & Struktur File Konfigurasi cloudbuild.yaml

File cloudbuild.yaml adalah blueprint utama dari pipeline CI/CD lu. Berkas ini memberi tahu Cloud Build urutan langkah eksekusi, kebutuhan hardware, hingga artefak apa yang harus disimpan.

Berikut komponen/field utama yang menyusun struktur cloudbuild.yaml:

1. steps (Kunci Utama / Mandatory)

Blok array berisi daftar urutan step yang akan dieksekusi.

• name: Docker image yang dipakai sebagai runner (misal: 'gcr.io/cloud-builders/docker', 'golang:1.22', 'ubuntu').

• args: Parameter CLI yang dikirim ke entrypoint bawaan kontainer (di-pass dalam bentuk array string).

• entrypoint: Mengunci atau mengganti command utama Docker image (misal: diganti jadi /bin/bash atau gcloud).

• script: Fitur modern untuk menulis perintah bash script multi-baris langsung tanpa perlu menyusun array args yang panjang.

• env: Menyimpan variabel lingkungan (environment variables) biasa.

• dir: Menentukan direktori kerja relatif dari /workspace (contoh: dir: 'src/backend').

• id: Memberi label/identitas unik pada step tertentu agar bisa diakses oleh step lain.

• waitFor: Mengatur urutan eksekusi atau eksekusi paralel. Jika diisi waitFor: ['-'], step akan langsung dijalankan di awal secara paralel tanpa menunggu step sebelumnya selesai.

• allowFailure: Jika bernilai true, kegagalan pada step ini tidak akan menggagalkan seluruh pipeline (berguna untuk non-blocking linting atau pengiriman notifikasi).

2. substitutions (Variabel Dinamis)

Menyediakan tempat untuk mendefinisikan variabel yang bisa di-pass secara dinamis saat trigger dipicu. GCP menyediakan variabel bawaan (built-in substitutions) seperti:

• $PROJECT_ID: ID project GCP.

• $BUILD_ID: ID unik proses build.

• $COMMIT_SHA / $SHORT_SHA: Commit hash git (Otomatis terisi saat dieksekusi via Git repository trigger. Jika dijalankan manual via CLI gcloud builds submit, variabel ini tidak terisi otomatis).

Lu juga bisa membuat variabel kustom yang wajib diawali garis bawah _ (contoh: _DEPLOY_REGION: 'asia-southeast1').

3. images

Daftar tag Docker image hasil kompilasi. Setelah pipeline selesai, Cloud Build akan otomatis mencatat metadata image ini di dashboard GCP Console History.

4. artifacts

Digunakan jika lu mau menyimpan output berupa file non-container (misal: file biner .zip, .jar, atau laporan code coverage). File ini otomatis diunggah ke GCS (Google Cloud Storage) bucket.

5. options

Mengatur perilaku runner dan alokasi infrastruktur:

• machineType: Menentukan spesifikasi hardware VM runner (E2_HIGHCPU_8, N1_HIGHCPU_32, dll).

• logging: Mengatur lokasi penyimpanan log (CLOUD_LOGGING_ONLY, GCS_ONLY).

• pool: Menentukan Private Pool jika build dijalankan di jaringan tertutup/VPC.

6. timeout & tags

• timeout: Mengatur batas waktu maksimal pipeline boleh berjalan (contoh: 1800s untuk 30 menit).

• tags: Memberi label teks untuk mempermudah pencarian/filtering build history di GCP Console.

Tahapan Memulai Cloud Build dari Nol

Kalau lu mau mulai pakai Cloud Build di GCP, berikut alur step-by-step yang perlu lu lakukan:

1. Aktifkan API yang Dibutuhkan

Buka GCP Console atau gunakan gcloud CLI buat mengaktifkan API Cloud Build beserta service pendukungnya:

gcloud services enable cloudbuild.googleapis.com artifactregistry.googleapis.com run.googleapis.com

2. Set Up Hak Akses Service Account (IAM)

Cloud Build bakal jalan pakai Service Account khusus (Formatnya: [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com atau Service Account kustom). Supaya Cloud Build bisa deploy aplikasi, lu harus kasih role yang sesuai di menu IAM:

• Artifact Registry Writer: Untuk me-push Docker image.

• Cloud Run Developer: Untuk melakukan deployment ke Cloud Run.

• Service Account User (roles/iam.serviceAccountUser): Izin penting agar Cloud Build dapat menempelkan identitas runtime (Service Account Runtime) ke aplikasi yang dideploy.

💡 Analogi Lengkap Ekosistem IAM & Deployment:

Bayangkan kamu lagi membangun dan mengelola sebuah properti perumahan:

• Rumah: Lingkungan/tempat aplikasi berjalan di GCP, seperti Cloud Run service atau GKE cluster.

• Penghuni: Aplikasi/program kamu yang nantinya akan tinggal dan aktif di dalam rumah tersebut.

• Kunci Rumah (Runtime Service Account): Akses/kunci khusus milik penghuni untuk membuka fasilitas perumahan (misal: akses ke Cloud SQL, GCS Bucket, atau Database).

• Tukang Bangunan / Kontraktor (Cloud Build / Build Service Account): Pihak yang bertugas merakit dan menyiapkan rumahnya (proses build & deploy). Saat bekerja, tukang bangunan ini menggunakan Pas ID sementara (Build Service Account).

• Surat Kuasa Penyerahan Kunci (roles/iam.serviceAccountUser): Izin resmi yang memberi wewenang ke Tukang Bangunan untuk menyerahkan Kunci Rumah (Runtime Service Account) kepada Penghuni (Aplikasi) saat pembangunan selesai. Tanpa surat kuasa ini, sistem GCP melarang tukang bangunan menyerahkan kunci rumah tersebut ke aplikasi.

3. Buat File cloudbuild.yaml di Root Project

Tambahkan file konfigurasi pipeline di dalam repositori kode aplikasi lu. File ini bakal mendefinisikan step-by-step kompilasi, testing, hingga deployment.

4. Hubungkan Repository & Buat Build Trigger

1. Masuk ke Cloud Build > Triggers di GCP Console.

2. Klik Connect Repository (pilih GitHub, GitLab, atau Cloud Source Repositories).

3. Buat Trigger Baru:

   • Event: Pilih pemicu (misalnya Push to a branch main).

   • Source: Pilih repository dan branch tujuan.

   • Configuration: Pilih Cloud Build configuration file (yaml or json) dan arahkan ke file /cloudbuild.yaml.

5. Test Run & Monitoring

Setiap ada git push ke branch target, Cloud Build bakal otomatis terpicu. Lu bisa memantau log jalannya proses build secara real-time di menu Cloud Build > History.

Contoh Skenario Sederhana Pipeline CI/CD (cloudbuild.yaml)

Berikut contoh pipeline CI/CD sederhana dan langsung siap pakai: unit test --> build Docker image --> push ke Artifact Registry --> deploy ke Cloud Run.

steps:
  # 1. Run Unit Tests & Linting
  - name: 'golang:1.22'
    entrypoint: 'go'
    args: ['test', '-v', './...']

  # 2. Build Docker Image
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'build'
      - '-t'
      - 'asia-southeast1-docker.pkg.dev/$PROJECT_ID/app-repo/backend-service:$SHORT_SHA'
      - '.'

  # 3. Push Image ke Artifact Registry
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'push'
      - 'asia-southeast1-docker.pkg.dev/$PROJECT_ID/app-repo/backend-service:$SHORT_SHA'

  # 4. Deploy ke Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args:
      - 'run'
      - 'deploy'
      - 'backend-service'
      - '--image=asia-southeast1-docker.pkg.dev/$PROJECT_ID/app-repo/backend-service:$SHORT_SHA'
      - '--region=asia-southeast1'
      - '--allow-unauthenticated'

# Menyimpan image tag untuk tracking di GCP Console
images:
  - 'asia-southeast1-docker.pkg.dev/$PROJECT_ID/app-repo/backend-service:$SHORT_SHA'

# Opsi mesin build
options:
  machineType: 'E2_HIGHCPU_8'
  logging: CLOUD_LOGGING_ONLY

Kenapa Banyak Tim DevOps Pindah ke Cloud Build?

1. Zero Infrastructure Maintenance

Gak ada lagi drama disk full di CI server atau dependency conflict antar-project. Tiap build mulai dari kondisi bersih (clean slate).

2. Kecepatan & Parallel Execution

Butuh kompilasi bahasa Go, Rust, atau Java yang makan memori gede? Lu tinggal ganti machine type di konfigurasi jadi N1_HIGHCPU_32 atau E2_HIGHCPU_8. Lu juga bisa nge-run beberapa step secara paralel pakai atribut waitFor.

3. Supply Chain Security Bawaan

Cloud Build udah mendukung standar keamanan SLSA Level 3. Artinya, secara otomatis lu dapet fitur vulnerability scanning buat Docker image dan pembuatan metadata provenance terverifikasi untuk mencegah tampering kode.

4. Dukungan Private Network (Private Pools)

Kalau database atau cluster Kubernetes lu ada di VPC tertutup tanpa IP publik, lu bisa pakai Cloud Build Private Pools. Fitur ini bikin runner Cloud Build bisa peering langsung ke jaringan VPC internal lu.

Perbandingan Cloud Build dan Jenkins

Biar makin jelas perbedaannya secara teknis dan operasional, berikut perbandingan langsung antara Cloud Build dan Jenkins:

Fitur / Parameter	GCP Cloud Build	Jenkins
Model Hosting	Fully Managed (Serverless)	Self-Hosted / Managed Server
Maintenance Effort	Hampir 0 (Google yang urus)	Tinggi (Update OS, plugin, disk, Java runtime)
Model Biaya	Pay-per-second build time	Bayar VM 24/7 (meski idle)
Integrasi GCP IAM	Native (Tanpa simpan credential/key)	Butuh Service Account Key JSON
Spesifikasi Hardware Runner	Bebas ganti via YAML (s/d 32 vCPU)	Tergantung kapasitas VM Jenkins
Ekosistem / Integrasi	Berbasis Docker Container	Ribuan Plugin Community
Kemudahan VPC Peering (Internal IP)	Sangat Mudah via Private Pools	Mudah (jika VM terpasang di VPC)

Pro-Tips Buat Optimasi Cloud Build

• Gunakan Tag $SHORT_SHA: Hindari pakai tag latest. Pakai commit hash ($SHORT_SHA) buat memudahkan proses rollback kalau ada bug lolos ke production. (Catatan: $SHORT_SHA otomatis terisi saat dieksekusi via Git repository trigger).

• Pakai Caching: Gunakan Kaniko atau Docker layer caching (--cache-from) agar waktu kompilasi tidak selalu dari nol.

• Manfaatkan Eksekusi Paralel (waitFor): Jika ada step independent (misalnya linting frontend dan backend secara bersamaan), hilangkan urutan sekuensial untuk mempercepat build time.

Kapan Harus Pakai Cloud Build?

• Cocok banget kalau: Workload aplikasi lu mendominasi ekosistem GCP (Cloud Run, GKE, Cloud Functions, Firebase) dan lu butuh CI/CD yang berskala otomatis tanpa mau repot maintenance server.

• Pertimbangkan alternatif kalau: Seluruh development workflow dan repositori lu udah terikat erat sama ekosistem Jenkins legacy yang butuh ribuan custom plugin, atau lu tidak menggunakan infrastruktur GCP sama sekali.