CI/CD dengan GitHub Actions: Dari Nol Hingga Produksi

CI/CD dengan GitHub Actions telah menjadi standar de-facto untuk merilis software secara andal dan cepat. Baik Anda developer solo maupun bagian dari tim engineering yang berkembang, mengotomasi tahap pengujian, build, dan deployment menghilangkan langkah manual yang melelahkan antara sebuah commit dan rilis yang live. Dalam panduan ini kita akan membangun pipeline siap produksi dari nol — mencakup workflow, penerbitan Docker image, deployment via SSH, dan praktik keamanan terbaik.

Memahami CI/CD dan GitHub Actions

Continuous Integration (CI) adalah praktik menjalankan pengujian secara otomatis setiap kali kode di-push. Continuous Deployment (CD) melangkah lebih jauh dengan mengirimkan build yang lolos secara otomatis ke environment staging atau produksi. GitHub Actions mengimplementasikan keduanya langsung di dalam repository menggunakan file workflow YAML yang disimpan di bawah .github/workflows/.

Anatomi File Workflow

Setiap workflow GitHub Actions diawali dengan trigger (on:), mendefinisikan satu atau lebih job, dan setiap job berisi rangkaian langkah. Langkah-langkah dapat berupa perintah shell atau marketplace action yang dapat digunakan kembali yang diterbitkan oleh komunitas. Job berjalan di virtual machine yang disebut runner — GitHub menyediakan runner Ubuntu, Windows, dan macOS yang di-hosting secara gratis dalam kuota bulanan.

Event dan Trigger

Workflow dapat dipicu oleh puluhan event: push, pull_request, schedule (cron), workflow_dispatch (manual), atau repository_dispatch (webhook eksternal). Menggunakan filter branch seperti 'branches: [main]' memastikan job deployment produksi Anda hanya berjalan ketika kode masuk ke branch main, bukan branch fitur.

Membangun dan Push Docker Image

Pipeline CI yang kuat membangun dan menandai Docker image pada setiap test run yang berhasil, kemudian mendorongnya ke container registry. Menggunakan docker/build-push-action bersama Docker Buildx memungkinkan fitur canggih seperti multi-platform build dan layer caching inline, yang secara drastis mengurangi waktu build pada run berikutnya.

Workflow YAML: Test → Build → Deploy

Workflow di bawah ini merangkai tiga job menggunakan kata kunci needs: untuk memastikan eksekusi berurutan. Test harus lulus sebelum image dibangun, dan image harus diterbitkan sebelum perintah SSH deployment berjalan. Ini memastikan kode yang rusak tidak pernah mencapai produksi.

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: myuser/myapp:latest,myuser/myapp:${{ github.sha }}

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.PROD_HOST }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            docker pull myuser/myapp:latest
            docker stop myapp || true
            docker rm myapp || true
            docker run -d --name myapp -p 3000:3000 myuser/myapp:latest

Mengoptimalkan Performa Build dengan Caching

Cache langkah npm ci install menggunakan actions/cache atau opsi cache: bawaan pada actions/setup-node. Untuk Docker, masukkan cache-from: type=registry ke docker/build-push-action agar layer yang tidak berubah diambil dari registry daripada dibangun ulang. Pada cache yang sudah hangat, waktu build turun dari beberapa menit menjadi di bawah 30 detik.

Strategi Deployment Tanpa Downtime

Langkah deployment yang menghentikan container yang berjalan sebelum memulai yang baru menciptakan jendela gangguan singkat. Dua pola sederhana menghindari ini: menggunakan kebijakan rolling update start-first Docker, atau menjalankan container baru sementara di port berbeda sebelum mengalihkan aturan load balancer.

Deployment Berbasis SSH dengan Health Check

Marketplace action appleboy/ssh-action memungkinkan Anda menjalankan perintah shell pada server remote melalui SSH tanpa memasang agen apa pun. Setelah menarik dan memulai container baru, tambahkan loop health check yang mem-poll endpoint /health dengan timeout sebelum menyatakan deployment berhasil.

Penguatan Keamanan Pipeline Anda

Pipeline yang menangani kredensial produksi adalah target bernilai tinggi. Kunci izin di level workflow dan job, pin action pihak ketiga ke commit SHA tertentu daripada tag yang dapat berubah, dan aktifkan required status checks agar branch main hanya dapat menerima kode melalui pull request yang telah direview.

Mem-pin Versi Action

Menggunakan 'actions/checkout@v4' mereferensikan tag yang dapat berubah. Seseorang dengan akses write ke repository tersebut dapat mengubah ke mana v4 mengarah. Mem-pin ke commit SHA penuh — 'actions/checkout@11bd719' — memastikan Anda selalu mendapatkan kode yang telah Anda review, menghilangkan risiko supply-chain.

OIDC Token: Autentikasi Cloud Tanpa Kunci Statis

Penyedia OIDC GitHub memungkinkan workflow Anda meminta JWT berumur pendek yang dipercaya langsung oleh penyedia cloud (AWS, GCP, Azure). Anda mengkonfigurasi trust policy di sisi cloud, lalu tidak ada secret statis yang tersimpan di repository Anda sama sekali — workflow menukar token OIDC dengan kredensial sementara saat runtime.

Matrix Build dan Pengujian Paralel

Strategi matrix GitHub Actions memungkinkan Anda menjalankan job yang sama di berbagai versi runtime, sistem operasi, atau variabel kustom secara paralel. Untuk proyek Node.js Anda mungkin menguji di Node 18, 20, dan 22 secara bersamaan, memotong total waktu CI hingga dua pertiga dibandingkan run berurutan.

Menggunakan matrix: untuk Menguji Berbagai Versi Node.js

Definisikan matrix dengan 'node-version: [18, 20, 22]' dan referensikan sebagai '${{ matrix.node-version }}' di dalam langkah setup-node. GitHub secara otomatis memfanout job ke tiga runner paralel. Jika salah satu versi gagal, pemeriksaan keseluruhan ditandai gagal, memberi Anda sinyal tepat tentang kompatibilitas.

Untuk memaksimalkan GitHub Actions, penting memahami istilah-istilah kunci: workflow trigger, job, marketplace action, repository secret, and runner.

Artikel Terkait

• Docker Best Practices untuk Container Produksi
• DevSecOps: Mengintegrasikan Keamanan ke dalam Pipeline Anda