Belajar Cloud Engineer - CI/CD di Cloud

#Pendahuluan

Sampai episode 13, seluruh deployment yang kalian lakukan — VM, cluster Kubernetes, fungsi serverless — masih dijalankan manual dari terminal. Itu bagus untuk belajar, tetapi tidak bisa dijadikan praktik produksi: satu kesalahan ketik, satu perintah yang terlewat, dan release jadi lambat atau rusak. Di sinilah CI/CD mengubah segalanya.

Episode 14 membahas CI/CD di cloud: AWS CodePipeline/CodeBuild, GCP Cloud Build, dan Azure DevOps. Kalian akan memahami alur pipeline modern — commit → build → test → deploy — bagaimana Terraform masuk ke dalamnya (dari episode 7), dan men-deploy aplikasi secara otomatis dari sebuah commit.

#Mengapa CI/CD Bukan Opsional

CI (Continuous Integration) — setiap commit otomatis di-build dan di-test, jadi masalah ditemukan dalam menit, bukan minggu. CD (Continuous Delivery/Deployment) — aplikasi yang lolos test otomatis di-deploy ke environment.

Manfaat yang terasa langsung:

1. Kecepatan — dari "6-8 minggu manual" ke "beberapa menit per commit".
2. Konsistensi — tidak ada lagi "di laptop saya jalan".
3. Rollback mudah — setiap deploy adalah artefak ber-versi yang bisa dikembalikan.
4. Auditable — siapa mengubah apa, kapan, semuanya tercatat di pipeline.

#Anatomi Pipeline

Pipeline CI/CD adalah alur bertahap:

[commit] → [build] → [test] → [deploy staging] → [approve] → [deploy prod]

Setiap tahap hanya berlanjut jika yang sebelumnya sukses. Gagal di test = tidak pernah sampai deploy.

#Pipeline dengan Cloud Build (GCP)

Contoh pipeline lengkap untuk aplikasi container. Definisi di cloudbuild.yaml:

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'asia-southeast2-docker.pkg.dev/$PROJECT_ID/lab-repo/webapp:$SHORT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'asia-southeast2-docker.pkg.dev/$PROJECT_ID/lab-repo/webapp:$SHORT_SHA']
  - name: 'gcr.io/cloud-builders/kubectl'
    args:
      - 'set'
      - 'image'
      - 'deployment/webapp'
      - 'webapp=asia-southeast2-docker.pkg.dev/$PROJECT_ID/lab-repo/webapp:$SHORT_SHA'
    env:
      - 'CLOUDSDK_COMPUTE_REGION=asia-southeast2'
      - 'CLOUDSDK_CONTAINER_CLUSTER=lab-cluster'
  - name: 'gcr.io/cloud-builders/kubectl'
    args: ['rollout', 'status', 'deployment/webapp']
    env:
      - 'CLOUDSDK_COMPUTE_REGION=asia-southeast2'
      - 'CLOUDSDK_CONTAINER_CLUSTER=lab-cluster'

gcloud builds triggers create github \
  --name=webapp-ci \
  --repo-owner=risa \
  --repo-name=webapp \
  --branch-pattern='^main$' \
  --build-config=cloudbuild.yaml

Setiap push ke main otomatis: build image → push ke Artifact Registry → update image deployment di cluster → tunggu rollout. Satu commit, aplikasi ter-deploy, tanpa manusia.

#Pipeline dengan CodePipeline (AWS)

AWS memakai kombinasi CodePipeline (orkestrasi) + CodeBuild (build):

version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.12
    commands:
      - pip install -r requirements.txt
  pre_build:
    commands:
      - python -m pytest --maxfail=1
  build:
    commands:
      - sam build
  post_build:
    commands:
      - sam deploy --no-fail-on-empty-changeset

Pipeline-nya:

aws codepipeline create-pipeline --cli-input-json file://pipeline.json

pipeline.json mendeskripsikan empat stage — Source (GitHub), Build (CodeBuild dengan buildspec.yaml), Deploy (SAM/CloudFormation), dan Approval (manual) — yang berjalan berurutan.

#Azure DevOps Pipeline

Azure DevOps punya pipeline dalam satu file YAML (azure-pipelines.yml):

trigger:
  branches:
    include:
      - main
 
pool:
  vmImage: ubuntu-latest
 
steps:
  - task: Docker@2
    inputs:
      containerRegistry: 'acr-lab'
      command: 'buildAndPush'
      repository: 'webapp'
      tags: '$(Build.BuildId)'
 
  - task: Kubernetes@1
    inputs:
      connectionType: 'Azure Resource Manager'
      azureSubscription: 'lab-sub'
      azureResourceGroup: 'rg-lab'
      kubernetesCluster: 'lab-cluster'
      command: 'set'
      arguments: 'image deployment/webapp webapp=acrlab.azurecr.io/webapp:$(Build.BuildId)'

#Peran Terraform dalam CI/CD

Infrastruktur juga harus melewati pipeline — ingat episode 7: IaC tanpa CI/CD adalah IaC setengah jadi. Pola yang benar:

# Tahap 1: plan (di PR) - jamin perubahan aman sebelum digabung
- name: terraform plan
  run: |
    terraform init
    terraform validate
    terraform plan -out=tfplan
 
# Tahap 2: apply (setelah merge ke main)
- name: terraform apply
  run: terraform apply -auto-approve tfplan

Alur lengkap di repositori infrastruktur:

1. PR dibuat → pipeline menjalankan terraform plan + tflint → hasil plan menjadi komentar review.
2. PR di-merge ke main → pipeline terraform apply → infrastruktur berubah.
3. Perubahan tercatat di history git — auditable penuh.

Inilah jawaban dari pertanyaan episode 7: state dipakai pipeline, bukan laptop. Remote state + locking (yang kita pasang saat itu) adalah prasyarat supaya pipeline ini aman.

#Praktik: Deploy App via Pipeline

Mari bangun pipeline utuh di provider yang kalian pilih:

1. Buat repo git untuk aplikasi web sederhana (yang sudah ada sejak episode 3).
2. Tambahkan test (minimal satu unit test) dan definisi pipeline (cloudbuild.yaml/buildspec.yaml/azure-pipelines.yml).
3. Buat trigger untuk branch main.
4. Push commit kecil, amati pipeline: build → test → deploy berjalan otomatis.
5. Push commit yang sengaja membuat test gagal → buktikan deploy tidak terjadi.
6. Tambahkan stage approval sebelum production (untuk latihan psikologis: manusia masih kadang diperlukan).

Setelah ini, aplikasi kalian punya alur release yang bisa diaudit, repeatable, dan bisa di-rollback. Ini menandai transisi dari "belajar" ke "praktik engineering".

#Kesalahan Umum (Common Pitfalls)

1. Semua di satu stage — pipeline raksasa yang susah didiagnosis; pecah jadi build/test/deploy.
2. Deploy langsung ke production tanpa gate — meskipun otomatis, gate manual untuk produksi penting di awal.
3. Credential di YAML — access key di pipeline file; pakai secret store/parameter (episode 15).
4. Tanpa test di pipeline — "pipeline" yang hanya build+deploy bukan CI/CD.
5. Terraform dijalankan manual, bukan pipeline — drift dan sejarah perubahan hilang; masukkan IaC ke pipeline.

#Penutup

Inti yang harus dibawa pulang:

• CI/CD mengotomasi commit → build → test → deploy; setiap commit kecil terverifikasi.
• Ketiga provider punya pipeline cloud-native: CodePipeline/CodeBuild, Cloud Build, Azure DevOps — konsep identik.
• Terraform masuk pipeline: plan saat PR, apply setelah merge — infrastruktur versioned dan auditable.
• Gate approval untuk production; rollback adalah fitur wajib, bukan rencana.
• Credential tidak pernah di YAML — selalu lewat secret store.

Di episode 15 selanjutnya kita akan membahas cloud security & compliance — encryption, secrets management (KMS/Secret Manager), security best practices, dan compliance (SOC2/GDPR) — lalu melakukan security audit cloud untuk infrastruktur kalian. Sampai jumpa di episode 15!