Cara Setup CI/CD dengan GitHub Actions

Setiap tim punya cerita deploy Jumat sore: perubahan kecil, "cuma satu baris", diunggah manual, dan akhir pekan pun hilang. Masalahnya bukan orangnya — manusia memang buruk dalam mengulang urutan langkah yang sama persis di bawah tekanan. CI/CD memindahkan urutan itu ke mesin: setiap perubahan kode diuji otomatis, dan yang lolos di-deploy dengan langkah yang identik setiap kali. Deploy berubah dari peristiwa menegangkan menjadi kejadian membosankan — dan membosankan, dalam urusan deploy, adalah pujian tertinggi.

Apa yang sebenarnya dilakukan CI/CD

Dua huruf pertama, Continuous Integration: setiap kali kode didorong ke repository, serangkaian pemeriksaan berjalan otomatis — test, linter, build. Kode yang merusak sesuatu ketahuan dalam hitungan menit, bukan saat pelanggan menelepon. Dua huruf kedua, Continuous Deployment: kode yang lolos pemeriksaan dan masuk branch utama diantar ke server otomatis. GitHub Actions menjalankan keduanya langsung dari repository GitHub Anda, dengan kuota gratis yang lebih dari cukup untuk proyek kecil-menengah.

Langkah 1: Kenali anatomi file workflow

Semua otomasi GitHub Actions hidup di file YAML dalam folder .github/workflows/. Anatominya tiga lapis: trigger (kapan jalan), job (apa yang dijalankan, di mesin apa), dan step (urutan perintahnya). Kerangka kosongnya:

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # langkah-langkah berikutnya di sini

Baris uses: memakai action — blok siap pakai dari marketplace; actions/checkout misalnya mengambil kode repository ke mesin runner. Selebihnya perintah shell biasa lewat run:.

Langkah 2: Jalankan test otomatis di tiap push

Contoh lengkap untuk proyek Python (pola Node.js identik, ganti setup dan perintahnya):

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest

Commit file ini, dorong ke GitHub, dan buka tab Actions: pemeriksaan pertama Anda sedang berjalan. Sejak menit ini, setiap pull request menampilkan centang hijau atau silang merah — dan tim punya fakta, bukan keyakinan, bahwa perubahan tidak merusak yang sudah ada. Syaratnya jujur: manfaat CI setinggi mutu test-nya. Proyek tanpa test tetap dapat nilai dari linter dan pemeriksaan build, tapi test dasar untuk alur paling penting adalah investasi pertama yang layak.

Langkah 3: Deploy otomatis saat merge ke main

Job kedua mengantar kode yang lolos ke server — contoh untuk deploy via SSH ke VPS seperti pada tutorial deploy VPS Ubuntu:

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: deploy
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /home/deploy/appku
            git pull
            .venv/bin/pip install -r requirements.txt
            sudo systemctl restart appku

Dua baris kecil yang memikul seluruh disiplinnya: needs: test berarti deploy hanya berjalan kalau test lolos, dan if: github.ref == 'refs/heads/main' membatasi ke branch utama. Digabung dengan aturan "main hanya menerima perubahan lewat pull request", hasilnya: tidak ada satu pun jalur menuju server yang melewati pengujian.

Langkah 4: Simpan rahasia di Secrets, bukan di kode

Alamat server dan kunci SSH di contoh tadi tidak ditulis di YAML — mereka dirujuk dari Settings → Secrets and variables → Actions di repository. Aturannya mutlak: kredensial apa pun yang pernah masuk ke riwayat git dianggap bocor, karena riwayat git tidak pernah benar-benar lupa. Untuk kunci SSH, buat keypair khusus deploy yang hanya dipakai pipeline ini — kalau harus dicabut, Anda mencabut kunci robot, bukan kunci pribadi siapa pun.

Kapan pipeline sederhana sudah cukup

Pipeline dua-job di atas — test lalu deploy — menutup kebutuhan sebagian besar aplikasi kecil dan menengah, dan kami sarankan bertahan di kesederhanaan itu selama mungkin. Tanda-tanda Anda butuh lebih: perlu lingkungan staging sebelum produksi, perlu rollback otomatis saat deploy gagal, beberapa layanan yang harus di-deploy serempak, atau proses build yang berat (image Docker, aplikasi mobile). Semua itu bisa dibangun di atas fondasi yang sama — tapi membangunnya sebelum dibutuhkan hanya menambah barang yang bisa rusak.

CI/CD paling terasa nikmatnya saat dipasangkan dengan alur kerja git yang rapi — pasangannya kami tulis di standar kerja tim software kami. Ingin pipeline seperti ini terpasang di proyek Anda tanpa mempelajari YAML-nya? Kami bisa bantu.