Cara Setup CI/CD Pipeline dengan GitHub Actions

Membuat Workflow File untuk Pipeline Pertama

Saatnya membuat file workflow pertama Anda. Buat file .github/workflows/deploy.yml di dalam repository. File ini mendefinisikan seluruh alur kerja pipeline, mulai dari trigger hingga langkah eksekusi yang akan dijalankan secara otomatis:

name: Pipeline Peluncuran Otomatis

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Ambil kode dari repository
        uses: actions/checkout@v4

      - name: Setup environment
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Instal dependensi
        run: npm ci

      - name: Jalankan pengujian
        run: npm test

  kirimkeserver:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Ambil kode dari repository
        uses: actions/checkout@v4

      - name: Kirim kode via SSH
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSHKEY }}
          port: ${{ secrets.PORT }}
          script: |
            cd /var/www/myapp
            git pull origin main
            npm ci --production
            pm2 restart myapp

Workflow ini menjalankan dua tahap berurutan: pengujian terlebih dahulu, lalu pengiriman ke server hanya jika pengujian berhasil. Kata kunci needs: test memastikan bahwa job pengiriman tidak akan berjalan sebelum job pengujian selesai tanpa error. Pendekatan berurutan ini adalah pola dasar yang harus diterapkan di setiap pipeline produksi.

Contoh Lengkap: Pipeline untuk Aplikasi Laravel

Untuk aplikasi berbasis PHP Laravel, pipeline perlu mengelola instalasi dependensi PHP, menjalankan migrasi basis data, dan mengoptimalkan konfigurasi. Berikut workflow lengkap yang bisa Anda gunakan langsung di proyek Laravel Anda:

name: Pipeline Laravel ke Server

on:
  push:
    branches: [ main ]

jobs:
  pengujian:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup PHP 8.3
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: mbstring, dom, zip, gd
      - name: Instal dependensi Composer
        run: composer install --no-dev --prefer-dist
      - name: Salin file konfigurasi
        run: cp .env.example .env
      - name: Generate kunci aplikasi
        run: php artisan key:generate
      - name: Jalankan pengujian unit
        run: php artisan test --parallel

  kirimkeserver:
    needs: pengujian
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Kirim ke Server
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSHKEY }}
          script: |
            cd /var/www/myapp
            git pull origin main
            composer install --no-dev --optimize-autoloader
            php artisan migrate --force
            php artisan config:cache
            php artisan route:cache
            php artisan view:cache
            sudo systemctl restart laravel-worker

Perhatikan penggunaan --parallel pada perintah pengujian. Kemampuan ini menjalankan beberapa file pengujian secara bersamaan, mempercepat proses secara cepat pada proyek dengan ratusan kasus uji. Pipeline ini juga menjalankan optimasi konfigurasi seperti caching route dan view, yang meningkatkan performa aplikasi di produksi. Pastikan file .env di server sudah dikonfigurasi dengan benar sebelum pipeline pertama kali dijalankan.

Contoh Lengkap: Pipeline untuk Aplikasi dengan Matrix Testing

Matrix testing memungkinkan Anda menguji aplikasi pada beberapa versi runtime secara paralel. Ini sangat berguna untuk memastikan kompatibilitas lintas versi sebelum mengirim kode ke lingkungan produksi. Strategi ini memastikan aplikasi Anda berjalan stabil di berbagai environment:

name: Pipeline Node.js dengan Matrix Testing

on:
  push:
    branches: [ main ]

jobs:
  pengujian:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x, 20.x, 22.x]
    steps:
      - uses: actions/checkout@v4
      - name: Gunakan Node.js versi matrix
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - name: Instal dependensi
        run: npm ci
      - name: Jalankan linting
        run: npm run lint
      - name: Jalankan pengujian
        run: npm test -- --coverage
      - name: Unggah laporan cakupan kode
        if: matrix.node-version == '20.x'
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

  kirimkeserver:
    needs: pengujian
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Kirim ke Server
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSHKEY }}
          script: |
            cd /var/www/myapp
            git pull origin main
            npm ci --production
            pm2 restart myapp

Strategi matrix menjalankan tiga versi runtime secara bersamaan dalam tiga runner terpisah. Laporan cakupan kode hanya diunggah dari satu versi (Node.js 20.x) untuk menghemat ruang penyimpanan artifacts. Jika salah satu versi gagal, pipeline akan menandai kegagalan tersebut di tab Actions sehingga tim bisa segera mengatasi masalah kompatibilitas. Penggunaan matrix testing adalah investasi kecil yang memberikan dampak besar pada keandalan aplikasi di lingkungan produksi.

Strategi Pengoptimalan dan Keamanan Pipeline

Setelah pipeline dasar berfungsi, langkah selanjutnya adalah mengoptimalkan kecepatan dan meningkatkan keamanan. Berikut beberapa strategi yang terbukti efektif dan bisa diterapkan secara bertahap sesuai kebutuhan proyek Anda.

Manajemen Cache Dependensi

Mengunduh ulang seluruh dependensi di setiap eksekusi pipeline membuang waktu berharga. Penggunaan cache bisa memangkas waktu build hingga lima puluh persen. Ini sangat berpengaruh pada proyek dengan jumlah dependency yang besar:

      - name: Cache node modules
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

Kunci cache dihitung berdasarkan hash file package-lock.json. Ketika file ini tidak berubah, pipeline akan menggunakan cache yang sudah ada daripada mengunduh ulang dari registry. Jika ada perubahan pada dependency, cache akan diperbarui secara otomatis. Strategi ini menghemat waktu dan juga mengurangi beban pada jaringan.

Pemindaian Keamanan Otomatis

Integrasikan pemindaian kerentanan ke dalam pipeline untuk mendeteksi masalah keamanan sejak tahap awal. Trivy adalah salah satu tools gratis yang sangat efektif untuk tujuan ini, dan sudah digunakan oleh ribuan tim pengembang di seluruh dunia:

      - name: Pemindaian kerentanan dengan Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL,HIGH'

Pengaturan exit-code: '1' memastikan pipeline langsung berhenti jika ditemukan kerentanan dengan tingkat CRITICAL atau HIGH. Ini mencegah kode dengan masalah keamanan kritis sampai ke produksi. Anda juga bisa mengintegrasikan Dependabot untuk pemindaian dependensi secara berkala dari menu Settings repository.

Perlindungan Branch Utama

Aktifkan opsi perlindungan branch di GitHub untuk memastikan semua perubahan melalui pull request yang di-review oleh minimal satu anggota tim. Fitur ini bisa diaktifkan di Settings, lalu Branches, lalu tambahkan branch protection rule. Aktifkan opsi berikut untuk menjaga kualitas kode di branch utama:

• Require a pull request before merging — memaksa semua perubahan melalui pull request yang di-review
• Require status checks — pipeline harus berhasil sebelum kode bisa digabungkan ke branch utama
• Require branches updated — kode harus diperbarui sebelum merge
• Prevent bypass — tidak ada yang boleh melewati aturan ini, termasuk administrator

Penggunaan Environment Variables

Pisahkan konfigurasi antara lingkungan staging dan produksi menggunakan environment variables. Ini memudahkan pengelolaan konfigurasi tanpa mengubah kode workflow. Setiap environment bisa memiliki nilai yang berbeda sesuai kebutuhan masing-masing:

jobs:
  kirimkeserver:
    environment: production
    runs-on: ubuntu-latest
    env:
      APPENV: production
      APPDEBUG: false
    steps:
      - uses: actions/checkout@v4
      - name: Kirim ke Server
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.HOST }}
          script: |
            cd /var/www/myapp
            export APPENV=production
            export APPDEBUG=false
            git pull origin main
            npm ci --production
            pm2 restart myapp

Dengan pendekatan ini, Anda bisa membuat lingkungan staging yang memiliki konfigurasi berbeda dari produksi tanpa perlu membuat workflow terpisah. Cukup definisikan environment di GitHub dan pipeline akan menggunakan nilai yang sesuai. Fitur environment protection rules juga memungkinkan Anda untuk menambahkan approval manual sebelum eksekusi ke produksi, memberikan lapisan keamanan tambahan yang sangat berguna bagi tim yang lebih besar.

Pertanyaan yang Sering Diajukan tentang CI/CD dengan Actions

Apakah GitHub Actions gratis untuk repository publik dan privat?

GitHub Actions memberikan akses gratis tanpa batas menit untuk repository publik. Untuk repository privat, Anda mendapat 2.000 menit per bulan secara gratis. Jika melebihi kuota, biaya tambahan dikenakan per menit berdasarkan jenis runner yang digunakan.

Bagaimana cara menjalankan pipeline secara manual tanpa push kode?

Gunakan trigger workflow_dispatch pada file workflow. Setelah dikonfigurasi, Anda bisa menjalankan pipeline dari tab Actions di repository GitHub dengan mengklik tombol Run workflow. Fitur ini sangat berguna untuk pengujian manual atau peluncuran darurat.

Bagaimana jika pipeline gagal di tengah eksekusi?

GitHub akan mengirimkan notifikasi email dan menampilkan log error detail di tab Actions. Anda bisa melihat langkah mana yang gagal, membaca log lengkapnya, dan menjalankan ulang pipeline dari langkah yang gagal tanpa perlu mengulang dari awal.

Berapa lama waktu yang dibutuhkan untuk menjalankan pipeline sederhana?

Untuk proyek sederhana dengan beberapa dependensi, pipeline biasanya selesai dalam 1 sampai 3 menit. Proyek yang lebih besar dengan ratusan dependensi dan pengujian komprehensif mungkin membutuhkan 5 sampai 15 menit. Penggunaan cache dependensi secara konsisten bisa memangkas waktu ini hingga lima puluh persen.

Apakah saya bisa menggunakan Actions untuk repository yang bukan milik saya?

Anda bisa menjalankan workflow di repository yang Anda fork, namun ada beberapa batasan. Workflow yang dipicu oleh event dari repository asli tidak akan berjalan kecuali Anda mengaktifkan opsi Actions di fork tersebut. Untuk repository orang lain, Anda tidak bisa menjalankan workflow tanpa izin akses.

Kesimpulan dan Langkah Selanjutnya

Membangun pipeline CI/CD dengan GitHub Actions merupakan investasi jangka panjang yang memberikan dampak nyata pada produktivitas dan keandalan tim pengembang. Dari persiapan server, konfigurasi rahasia repository, hingga pembuatan workflow yang mencakup pengujian otomatis dan pengiriman ke produksi, setiap langkah yang telah dibahas bisa diterapkan langsung ke proyek Anda.

Mulai dengan pipeline sederhana yang hanya melakukan checkout kode dan menjalankan pengujian. Setelah nyaman, tambahkan tahap pengiriman ke server, caching dependensi, dan pemindaian keamanan secara bertahap. Hindari mencoba menerapkan semuanya sekaligus — pendekatan iteratif memberikan hasil yang lebih baik dan mengurangi risiko kesalahan konfigurasi. Tim yang sukses menerapkan CI/CD biasanya memulai dari satu workflow sederhana, lalu berekspansi seiring bertambahnya kebutuhan proyek.

Jika Anda ingin mempelajari lebih lanjut tentang praktik DevOps lainnya, baca juga panduan kami tentang cara deploy aplikasi Docker ke VPS dan best practices microservices architecture untuk memperluas pemahaman Anda tentang arsitektur perangkat lunak modern.

Sumber Referensi

1. GitHub Actions Quickstart — Dokumentasi Resmi GitHub
2. Workflow Syntax — Referensi Sintaks YAML GitHub Actions
3. DevOps Essentials: CI/CD Pipeline dengan GitHub Actions — Pradha.id
4. CI/CD Auto Deploy ke VPS Linux — Sufanet
5. Setup CI/CD Pipeline dengan GitHub Actions — RumahCoding