Belajar DevOps Engineer - CI/CD Lanjutan & Cache

#Pendahuluan

Di episode 5 dan 6 kalian membangun pipeline CI dan CD yang berfungsi. Tetapi "berfungsi" dan "cepat" adalah dua hal yang berbeda. Pipeline yang memakan 40 menit untuk satu commit membuat developer kehilangan fokus, feedback datang terlambat, dan lead time merayap naik. DORA metrics (yang akan dibahas di episode 26) menempatkan lead time sebagai metrik inti — dan pipeline adalah tempat lead time lahir.

Episode 21 membekali kalian dengan teknik optimasi pipeline yang nyata: parallel jobs, caching, matrix builds, dan pola pipeline-as-code — lalu mengukur hasilnya. Karena apa pun yang tidak diukur tidak akan membaik.

#Paralelisme: Pekerjaan yang Saling Bebas

Kesalahan paling umum pipeline pertama: semua langkah berjalan berurutan, padahal banyak di antaranya saling bebas. Job lint, test, dan build tidak perlu menunggu satu sama lain. Memecah pipeline menjadi job paralel adalah kemenangan tercepat:

name: CI
on: [push, pull_request]
 
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci
      - run: npm run lint
 
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci
      - run: npm test
 
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci
      - run: npm run build

Ketiga job berjalan bersamaan; durasi pipeline menjadi durasi job terlama, bukan jumlah semuanya.

#Caching: Jangan Unduh Ulang yang Sudah Ada

Dependency yang diunduh ulang setiap job adalah pemborosan terbesar. Caching menyimpan dependency antar-run sehingga npm ci berubah dari menit menjadi detik:

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: 22
      cache: npm
  - run: npm ci

cache: npm memanfaatkan hash package-lock.json sebagai kunci: selama lockfile tidak berubah, dependency diambil dari cache. Pola yang sama berlaku untuk pip, Maven, Go, dan lainnya — prinsipnya identik: cache sesuai fingerprint dependency, dan invalidate hanya saat dependency berubah.

Di GitLab CI, konsepnya serupa:

cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/
 
test:
  script:
    - npm ci
    - npm test

#Matrix Builds: Uji Banyak Konfigurasi Sekali

Jika aplikasi harus bekerja di banyak runtime atau OS, matrix build menjalankan job yang sama pada setiap kombinasi tanpa menyalin YAML:

strategy:
  matrix:
    node: [18, 20, 22]
    os: [ubuntu-latest, windows-latest]
 
runs-on: ${{ matrix.os }}
 
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: ${{ matrix.node }}
  - run: npm ci
  - run: npm test

Matrix mengubah "aku tidak tahu apakah lulus di Node 20" menjadi jawaban mesin dalam satu push. Gunakan dengan bijak: setiap kombinasi adalah biaya runner; batasi pada kombinasi yang benar-benar didukung.

#Pola Pipeline-as-Code yang Teruji

#Reusable Workflow

Konfigurasi pipeline yang disalin antar-repository adalah sumber drift. Reusable workflow memaketkan langkah umum (misal "build-node-app") agar dipakai ulang dan diperbarui di satu tempat:

on:
  workflow_call:
    inputs:
      node-version:
        type: string
        default: "22"
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
      - run: npm ci
      - run: npm run build

jobs:
  build-app:
    uses: ./.github/workflows/build-node.yml
    with:
      node-version: "22"

#Fail Fast dan Dependent Gate

Job yang bergantung pada job lain menggunakan needs — build hanya berjalan jika lint dan test hijau:

jobs:
  lint: { ... }
  test: { ... }
  build:
    needs: [lint, test]
    steps:
      - run: npm run build

#Praktik: Optimasi dan Ukur

Alur optimasi yang bisa kalian ikuti langsung:

1. Ukur baseline — catat durasi setiap job dari run terakhir.
2. Identifikasi bottleneck — job mana yang paling lama? Biasanya dependency install.
3. Pasang cache — dependency dan build artifacts.
4. Paralelkan — pisahkan job yang saling bebas.
5. Ukur lagi — bandingkan, catat di README, ulangi.

gh run list --workflow=ci.yml --limit 5
gh run view <run-id> --json jobs --jq '.jobs[] | {name, duration: .completed_at}'

Sebuah tim yang mengubah pipeline dari 30 menit menjadi 8 menit menghemat lebih dari 180 jam developer per bulan (dengan 20 developer) — bukan angka yang kecil.

#Pitfall Umum

• Cache yang tidak invalidasi — kunci cache harus menyertakan fingerprint dependency; kalau tidak, hasil test bisa basi.
• Paralelisme yang boros — jangan pecah job menjadi banyak runner kecil; overhead bisa melebihi manfaat.
• Matrix yang tak terkendali — setiap kombinasi menambah biaya; hanya kombinasi yang didukung.
• Cache rahasia — jangan pernah menaruh secret di file yang di-cache.
• Mengukur kesuksesan dari kecepatan saja — pipeline cepat yang sering merah tetap buruk; keandalan dan kecepatan diukur bersamaan.

#Penutup

Inti yang harus dibawa pulang:

• Paralelisme memecah job yang saling bebas; caching menghilangkan pengunduhan berulang — dua optimasi terbesar.
• Matrix builds menguji banyak konfigurasi dari satu definisi.
• Reusable workflow dan needs membuat pipeline as-code terpelihara dan terkendali.
• Ukur sebelum dan sesudah — optimasi tanpa pengukuran adalah dugaan.

Di episode 22 selanjutnya kita membahas Cost Optimization (FinOps) — mengelola biaya cloud yang semakin menjadi beban utama organisasi: cost tracking, tagging, right-sizing, dan budget alerts. Kecepatan pipeline yang kalian optimalkan di episode ini kini harus diiringi efisiensi biaya.