Belajar Platform Engineer - CI/CD Platform

#Pendahuluan

Setelah di episode 6 kita membangun portal (Backstage) sebagai wajah platform, episode ini melengkapi alur paling penting yang developer pakai setiap hari: CI/CD. Di banyak organisasi, pipeline CI/CD adalah "wild west" — setiap tim punya pipeline sendiri, cara build sendiri, dan registri sendiri. Platform engineer mengubah ini menjadi produk: pipeline yang distandardisasi, aman secara default, dan terukur.

Mengapa CI/CD harus jadi platform, bukan kumpulan workflow? Karena pipeline adalah titik di mana kode berubah menjadi produksi — titik paling berisiko dalam siklus release. Pipeline yang tidak terstandarisasi berarti: cara deploy yang berbeda-beda, image yang tidak konsisten, dan tidak ada jaminan bahwa apa yang diuji adalah apa yang di-deploy.

#Prinsip CI/CD Platform

Empat prinsip yang menjadi kompas perancangan:

1. Satu pola, banyak tim — template pipeline dimiliki platform team; tim memakai, bukan membangun.
2. Secure by default — signing image, scan vulnerability, dan secrets yang aman aktif sejak awal (detail di episode 19).
3. Reproducible — hasil build hari ini bisa direproduksi besok; image immutable dengan tag SHA.
4. Observable — setiap pipeline menghasilkan metrics dan log yang bisa dipantau platform.

#Pipeline Template: Satu Pola untuk Semua

Kuncinya adalah template, bukan dokumentasi. Jika cara deploy hanya dijelaskan di dokumen, setiap tim akan menginterpretasikan dengan caranya sendiri. Jika cara deploy adalah template yang harus dipakai, konsistensi terjamin.

#Template GitHub Actions (contoh untuk containerized service)

name: Service Build & Deploy
on:
  workflow_call:
    inputs:
      environment:
        type: string
        required: true
      image-name:
        type: string
        required: true
    secrets:
      REGISTRY_PASSWORD:
        required: true
      DEPLOY_TOKEN:
        required: true
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Build image
        run: docker build -t ${{ vars.REGISTRY }}/${{ inputs.image-name }}:${{ github.sha }} .
 
      - name: Scan vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ vars.REGISTRY }}/${{ inputs.image-name }}:${{ github.sha }}
          severity: CRITICAL,HIGH
 
      - name: Sign image
        uses: sigstore/cosign-installer@v3
      - run: cosign sign ${{ vars.REGISTRY }}/${{ inputs.image-name }}:${{ github.sha }}
 
      - name: Push image
        run: docker push ${{ vars.REGISTRY }}/${{ inputs.image-name }}:${{ github.sha }}

Template ini menjadi workflow_call — service kalian tinggal memanggilnya:

name: Deploy payments-api
on:
  push:
    branches: [main]
jobs:
  deploy:
    uses: org/platform-workflows/.github/workflows/template-service.yml@main
    with:
      environment: prod
      image-name: payments-api
    secrets: inherit

Perhatikan transfer pengetahuan yang terjadi: semua kompleksitas build, scan, signing dipindahkan ke satu tempat. Tim payments tidak perlu tahu detail cosign atau trivy — mereka tinggal memanggil template. Ini contoh nyata abstraksi CI/CD sebagai produk.

#Artifact Registry sebagai Produk

Artifact registry (container image, package, helm chart) adalah bagian CI/CD yang paling sering diremehkan tapi paling berdampak. Platform engineer menganggap registry sebagai produk dengan aturan:

Kebijakan "image immutable + tag SHA" adalah yang paling penting: apa yang di-deploy hari ini harus bisa ditelusuri ke commit tertentu — kemampuan yang tidak dimiliki tag latest yang menyesatkan.

#Pola Pipeline yang Konsisten

Satu pola pipeline untuk service containerized (bisa disesuaikan per jenis workload):

1. Build — compile + build image dengan cache yang efisien.
2. Test — unit + integration test; gagal berarti stop.
3. Scan — CVE scan; CRITICAL/HIGH = block.
4. Sign — tanda tangan image untuk supply chain security.
5. Push — image masuk registry dengan tag SHA.
6. Deploy — update manifest (GitOps akan menyinkronkannya, lihat episode 5).
7. Verify — smoke test pasca-deploy; rollback otomatis jika gagal.

#Environment Promotion

Platform engineer juga menetapkan jenjang environment yang konsisten: dev → staging → prod. Setiap jenjang punya gate:

dev      : push ke branch feature/main -> auto-deploy, no gate
staging  : PR merge ke main -> auto-deploy, butuh smoke test pass
prod     : tag release (v*) -> manual approval + runbook rollback

Gate yang jelas mencegah dua masalah klasik: deploy sembarangan ke prod, dan pipeline yang macet karena setiap deploy butuh approval manual.

#Merge Queue dan Deployment Strategy

Untuk tim besar, antrean merge dan strategi deploy adalah bagian dari platform CI/CD:

• Merge queue (mis. GitHub Merge Queue) — mencegah antar-merge saling merusak di main.
• Deployment strategy — default yang direkomendasikan: rolling update untuk sebagian besar, blue-green untuk service yang butuh zero-downtime terjamin, canary untuk perubahan berisiko tinggi.

# Pola yang direkomendasikan platform
strategy:
  type: RollingUpdate   # default
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Kita tidak perlu menerapkan semua strategi — yang perlu platform lakukan adalah menetapkan default dan menyediakan opsi terdokumentasi.

#Observability Pipeline

Pipeline CI/CD harus diamati seperti sistem lain. Metrics yang paling penting:

Empat yang terakhir adalah DORA metrics yang kita bahas lebih dalam di episode 22. Untuk sekarang: pastikan setiap pipeline mengirim metrics ke stack observability (episode 9), dan tim platform punya dashboard sendiri untuk CI/CD health.

#Common Pitfalls

1. Template yang tidak di-versioning — mengubah template langsung merusak semua pipeline yang sedang berjalan.
2. Tag latest untuk deploy — menelusuri "mana commit yang menyebabkan bug" menjadi tidak mungkin.
3. Gate di semua jenjang — approval manual di dev/staging membuat pipeline macet; simpan approval untuk prod.
4. Secrets di pipeline config — secret harus dari vault/keychain (episode 10), bukan di YAML repo.
5. Build lokal yang tidak reproducible — tanpa base image yang dipin dan lockfile, "works on my machine" kembali muncul.

#Penutup

Inti yang harus dibawa pulang:

• CI/CD sebagai platform = satu template, banyak tim, bukan dokumentasi per tim.
• Artifact registry dengan image immutable (tag SHA) + scan + sign + retention.
• Pola pipeline konsisten: build → test → scan → sign → push → deploy → verify.
• Ukur pipeline dengan DORA metrics setelah standardisasi.

Di episode 8 selanjutnya kita masuk ke jaringan: service mesh & networking — Istio/Linkerd, mTLS, dan traffic management yang menjadi lapisan kontrol komunikasi antar-service di platform. CI/CD yang hebat tetap butuh jaringan yang benar untuk deliver trafik yang benar!