Memahami CI/CD dari Commit sampai Deployment

CI/CD sering dibicarakan sebagai satu hal, padahal isinya adalah serangkaian kebiasaan yang membuat perubahan kode dapat dirilis dengan aman dan berulang. Artikel ini mengikuti perjalanan satu commit, dari laptop developer sampai melayani pengguna di production.

CI, Continuous Delivery, dan Continuous Deployment

Ketiga istilah ini saling berkaitan, tetapi menjawab pertanyaan yang berbeda.

Banyak tim memulai dari CI, lalu Continuous Delivery. Continuous Deployment baru masuk akal ketika test dan monitoring sudah cukup dipercaya untuk menggantikan pemeriksaan manual.

Perjalanan sebuah commit

1. Commit dan pull request

Perubahan dimulai di branch terpisah dan diajukan melalui pull request. Di tahap ini pipeline CI berjalan untuk pertama kalinya, sehingga reviewer dapat melihat apakah perubahan merusak build atau test sebelum membaca kodenya.

2. Continuous Integration: build dan test

CI menjalankan langkah yang sama di lingkungan bersih setiap kali ada perubahan. Urutannya biasanya dari yang paling cepat gagal:

1. Instal dependensi dari lockfile agar versinya konsisten.
2. Lint dan pemeriksaan tipe untuk menangkap kesalahan sederhana.
3. Unit test, lalu integration test bila tersedia.
4. Build aplikasi.

3. Artefak yang immutable

Setelah build berhasil, hasilnya dikemas menjadi artefak, misalnya image Docker. Prinsip pentingnya: bangun sekali, deploy berkali-kali. Artefak yang sama dipromosikan dari staging ke production, bukan dibangun ulang, sehingga yang diuji adalah persis yang dirilis.

Beri tag artefak dengan identitas yang unik, seperti SHA commit. Tag latest tidak memberi tahu versi mana yang sedang berjalan dan menyulitkan rollback.

4. Deploy ke staging

Staging adalah environment yang semirip mungkin dengan production. Di sini integrasi dengan database, layanan eksternal, dan konfigurasi nyata diuji. Konfigurasi dan secret diberikan melalui environment, bukan ditanam di dalam artefak.

5. Rilis ke production

Pada Continuous Delivery, rilis dipicu oleh persetujuan, misalnya melalui environment protection rule. Pada Continuous Deployment, langkah ini berjalan otomatis. Keduanya sebaiknya diakhiri dengan health check dan pemantauan metrics setelah rilis.

Contoh workflow GitHub Actions

Workflow berikut menjalankan test pada setiap pull request, lalu membangun dan mempublikasikan image ke GitHub Container Registry ketika ada push ke main.

name: CI
 
on:
  pull_request:
  push:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
 
  publish:
    needs: test
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Beberapa hal yang perlu diperhatikan:

• needs: test memastikan image hanya dipublikasikan bila test lulus.
• permissions dibatasi seperlunya. Token default hanya diberi akses tulis ke packages.
• Tag memakai github.sha sehingga setiap image dapat ditelusuri ke commit asalnya.

Strategi deployment

Cara mengganti versi lama dengan versi baru memengaruhi risiko dan kebutuhan infrastruktur.

Rollback: rencanakan sejak awal

Rollback yang baik adalah rollback yang sudah pernah dicoba. Dengan artefak immutable, rollback cukup berarti menjalankan kembali tag versi sebelumnya. Hal yang lebih sulit adalah perubahan database: buat migrasi yang kompatibel ke belakang, misalnya menambah kolom baru terlebih dahulu dan baru menghapus kolom lama di rilis berikutnya.

Kesalahan umum

• Membangun ulang artefak per environment. Hasilnya bisa berbeda dari yang diuji.
• Test yang tidak stabil dibiarkan. Tim akan terbiasa mengabaikan pipeline merah.
• Tidak ada health check. Container yang berjalan belum tentu aplikasinya sehat.
• Pipeline hanya dipahami satu orang. Simpan konfigurasi di repository dan dokumentasikan alurnya.

Penutup

CI/CD bukan soal tools tertentu, melainkan tentang membuat setiap langkah rilis dapat diulang, diamati, dan dibatalkan. Mulailah dari CI yang andal, lanjutkan dengan artefak yang immutable, lalu otomatisasi deployment sedikit demi sedikit seiring meningkatnya kepercayaan terhadap test dan monitoring Anda.