CI/CD Pipeline dengan GitHub Actions: Panduan

Deploy manual ke production adalah proses yang rawan human error: SSH ke server, pull code, install dependencies, rebuild, restart service, dan rollback manual jika terjadi error. Proses ini memakan waktu 15-30 menit per deploy. Satu kesalahan kecil — misalnya lupa menginstall dependency baru di production — bisa membuat website down selama berjam-jam sebelum terdeteksi.

CI/CD pipeline menggunakan GitHub Actions menghilangkan masalah ini. Setiap push ke branch main, pipeline berjalan otomatis: test, build, dan deploy ke production. Proses yang tadinya 30 menit menjadi 3-5 menit, dengan testing otomatis yang memastikan kode baru tidak merusak fitur yang sudah ada. Artikel ini membahas cara membangun pipeline CI/CD lengkap — dari testing otomatis, build, hingga deployment ke VPS dengan zero-downtime.

Apa itu CI/CD dan Kenapa Penting

CI (Continuous Integration) adalah praktik di mana developer secara rutin menggabungkan code changes ke repository bersama. Setiap merge, automated tests dijalankan untuk memastikan kode baru tidak merusak fitur yang sudah ada. CD (Continuous Delivery/Deployment) adalah ekstensi dari CI — setelah kode teruji, otomatis di-deploy ke environment production atau staging.

Untuk freelancer dan indie developer, CI/CD bukan kemewahan — ini kebutuhan. Dengan pipeline yang proper, developer bisa: (1) deploy dengan percaya diri karena semua test sudah dijalankan, (2) rollback cepat jika ada masalah, (3) fokus menulis kode alih-alih memikirkan proses deployment, dan (4) membuat project terlihat lebih profesional di mata klien.

GitHub Actions dipilih karena integrasinya yang seamless dengan GitHub — standar industri untuk hosting repository. Untuk repository publik, GitHub Actions gratis tanpa batas menit pada standard GitHub-hosted runners; untuk repository privat di plan Free tersedia 2.000 menit per bulan. Selain itu, GitHub mengumumkan penurunan harga hosted runners hingga 39% per 1 Januari 2026 dan menunda perubahan billing untuk self-hosted runners (lihat Sumber & Validasi di bawah).

Setup Project untuk CI/CD

Sebelum membuat pipeline, pastikan project sudah memiliki beberapa hal berikut:

1. Package.json dengan scripts yang proper. Minimal harus ada test, build, dan start scripts. Contoh untuk project Node.js:

{
  "scripts": {
    "test": "jest --coverage",
    "build": "next build",
    "start": "next start",
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx"
  }
}

2. Test suite yang meaningful. Tidak perlu coverage 100%, tapi setidaknya ada test untuk critical paths — authentication, payment flow, core business logic. Untuk project Next.js, Jest + React Testing Library sudah lebih dari cukup.

3. Environment variables ter-dokumentasi. Buat .env.example yang mendaftar semua variables yang dibutuhkan tanpa values-nya. Ini penting karena CI/CD perlu tahu apa saja yang harus di-setup.

4. SSH access ke server deployment. Diperlukan SSH key pair untuk akses server dari GitHub Actions. Generate key baru khusus CI/CD, jangan pakai key personal.

Membuat Workflow GitHub Actions

Buat file .github/workflows/deploy.yml di root project. Ini skeleton yang umum dipakai:

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /srv/web/my-project
            git pull origin main
            npm ci --production
            npm run build
            sudo systemctl restart my-project

Penjelasan workflow-nya:

Trigger: Pipeline berjalan setiap push ke branch main. Ini kondisi paling umum untuk CI/CD.

Job test: Ini bagian CI-nya. Checkout code, setup Node.js, install dependencies (pakai npm ci untuk hasil deterministik), jalankan linting dan test. Jika ada test yang gagal, pipeline berhenti — kode tidak di-deploy.

Job deploy: Ini bagian CD-nya. Hanya berjalan jika (1) semua test pass, DAN (2) push ke branch main. Deploy memakai SSH action — pull code terbaru di server, install dependencies, build, dan restart service.

Secrets Management

Jangan pernah hardcode credentials di workflow file. Gunakan GitHub Secrets: pergi ke Settings → Secrets and variables → Actions → New repository secret. Tambahkan SERVER_HOST, SERVER_USER, dan SSH_PRIVATE_KEY.

Untuk SSH key khusus CI/CD, generate baru dengan ssh-keygen -t ed25519. Public key diletakkan di server, private key disimpan di GitHub Secrets. Penting: buat user khusus deploy di server, jangan pakai root atau user personal. Prinsip least privilege.

Zero-Downtime Deployment

Basic deployment punya satu masalah: saat systemctl restart berjalan, website down beberapa detik. Solusi: symlink swap. Build baru ditulis ke lokasi temporary, lalu symlink di-swap secara atomic. Server langsung menunjuk ke build baru tanpa downtime. Dan gunakan systemctl reload (bukan restart) supaya process menerima SIGHUP dan reload config tanpa kill dan start ulang.

Testing Pipeline Strategy

Ada tiga layer testing yang direkomendasikan:

Layer 1: Lint & Format Check — ESLint + Prettier. Paling cepat (kurang dari 30 detik). Jika layer ini gagal, pipeline berhenti.

Layer 2: Unit Tests — Jest atau Vitest. Target: critical paths saja. Tidak perlu mencoba menutupi semua edge case di CI.

Layer 3: Integration Tests — Test flow end-to-end. Misalnya: buat user, login, buat order, bayar. Lebih lambat tapi berharga untuk menangkap regression bugs.

Pisahkan layer ini menjadi separate jobs di GitHub Actions supaya bisa parallel execution. Jika lint gagal, hasilnya terlihat dalam 30 detik — tidak perlu menunggu 5 menit test selesai.

Monitoring Post-Deployment

Deploy bukan akhir — perlu dipastikan apakah deploy berhasil. Setelah deploy, pipeline menjalankan health check: tunggu 30 detik, lalu hit endpoint health. Jika status bukan 200, pipeline gagal dan notifikasi terkirim. Telegram notification yang mengirim pesan ke chat pribadi saat deploy gagal adalah praktik yang terbukti menyelamatkan dari undetected downtime.

Kesimpulan

CI/CD dengan GitHub Actions adalah investasi yang langsung terasa ROI-nya. Selain menghemat waktu deployment (dari 30 menit menjadi 5 menit), pipeline otomatis menghilangkan stres "jangan sampai salah deploy". Mulai dari yang sederhana: test + deploy via SSH. Setelah nyaman, tambahkan health check, notification, dan zero-downtime strategy.

Sumber & Validasi

Informasi pada artikel ini divalidasi terhadap dokumentasi resmi dan sumber berikut:

• Dokumentasi resmi GitHub Actions — referensi workflows, jobs, steps, dan actions.
• About workflows — GitHub Docs — penjelasan trigger, syntax, dan konsep workflow.
• About billing for GitHub Actions — kuota gratis repository publik dan menit gratis plan Free untuk repository privat.
• Pricing changes for GitHub Actions 2026 — penurunan harga hosted runners hingga 39% per 1 Januari 2026 dan penundaan perubahan billing self-hosted.

Baca juga: Gitea Actions: CI/CD Self-Hosted Gratis untuk alternatif CI/CD self-hosted tanpa batas menit, atau Panduan Memulai Jasa Deployment VPS untuk membangun layanan deployment sebagai freelancer.