Dulu, setiap kali gue push code ke production, itu prosesnya manual banget: SSH ke server, pull code, install dependencies, rebuild, restart service. Kalau ada error? Rollback manual juga. Proses ini makan waktu 15-30 menit setiap deploy, dan yang lebih parah, sering ada human error. Salah satu kali, gue lupa install dependency baru di production — website down selama 2 jam sebelum gue sadar.
Semua itu berubah setelah gue implement CI/CD pipeline pakai GitHub Actions. Sekarang, setiap kali gue push code ke branch main, pipeline jalan otomatis: test, build, deploy ke production. Proses yang tadinya 30 menit sekarang cuma 3-5 menit, dan yang paling penting, zero human error. Artikel ini bakal guide lo step-by-step membangun pipeline yang sama.
Apa itu CI/CD dan Kenapa Penting
CI (Continuous Integration) adalah practice di mana developer secara rutin merge code changes ke repository bersama. Setiap merge, automated tests jalan untuk memastikan code baru nggak ngerusak fitur yang udah ada. CD (Continuous Delivery/Deployment) adalah extension dari CI — setelah code teruji, otomatis di-deploy ke environment production atau staging.
Untuk freelancer dan indie developer, CI/CD itu bukan luxury — ini kebutuhan. Dengan pipeline yang proper, lo bisa: (1) deploy dengan confidence karena semua test udah jalan, (2) rollback cepat kalau ada masalah, (3) fokus nulis code alih-alih mikirin deployment process, dan (4) bikin project keliatan lebih profesional di mata klien.
GitHub Actions jadi pilihan gue karena integrasinya seamless dengan GitHub — yang mana udah jadi standar industri. Free tier-nya juga cukup generous: 2,000 menit per bulan untuk public repos, dan 2,000 menit juga untuk private repos di plan free.
Setup Project untuk CI/CD
Sebelum bikin pipeline, pastikan project lo udah punya beberapa hal ini:
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. Nggak usah coverage 100%, tapi setidaknya ada test untuk critical paths — authentication, payment flow, core business logic. Kalau lo pake Next.js, Jest + React Testing Library udah lebih dari cukup.
3. Environment variables ter-dokumentasi. Bikin .env.example yang list semua variables yang dibutuhkan, tanpa values-nya. Ini penting karena CI/CD butuh tau apa aja yang perlu di-setup.
4. SSH access ke server deployment. Lo butuh SSH key pair untuk akses server dari GitHub Actions. Generate key baru khusus untuk CI/CD, jangan pake key personal lo.
Membuat Workflow GitHub Actions
Buat file .github/workflows/deploy.yml di root project. Ini skeleton yang gue pake:
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 jalan setiap push ke branch main. Ini kondisi paling umum untuk CI/CD.
Job test: Ini CI-nya. Checkout code, setup Node.js, install dependencies (pakai npm ci untuk deterministik), jalankan linting dan test. Kalau ada test yang fail, pipeline berhenti — code nggak di-deploy.
Job deploy: Ini CD-nya. Hanya jalan kalau (1) test semua pass, DAN (2) push ke branch main. Deploy pakai SSH action — pull code terbaru di server, install dependencies, build, dan restart service.
Secrets Management
Jangan pernah hardcode credentials di workflow file. Pakai GitHub Secrets: pergi ke Settings → Secrets and variables → Actions → New repository secret. Tambahin SERVER_HOST, SERVER_USER, dan SSH_PRIVATE_KEY.
Untuk SSH key khusus CI/CD, generate baru pakai ssh-keygen -t ed25519. Public key taruh di server, private key taruh di GitHub Secrets. Penting: bikin user khusus deploy di server, jangan pake root atau user personal. Principle of least privilege.
Zero-Downtime Deployment
Basic deployment punya satu masalah: saat systemctl restart jalan, website down beberapa detik. Solusi: symlink swap. Build baru ditulis ke lokasi temporary, lalu symlink di-swap secara atomic. Server langsung point ke build baru tanpa downtime. Dan pake systemctl reload (bukan restart) supaya process menerima SIGHUP dan reload config tanpa kill dan start ulang.
Testing Pipeline Strategy
Gue pake tiga layer testing:
Layer 1: Lint & Format Check — ESLint + Prettier. Paling cepat (kurang dari 30 detik). Kalau ini fail, jangan lanjut.
Layer 2: Unit Tests — Jest atau Vitest. Target: critical paths only. Jangan try cover semua edge case di CI.
Layer 3: Integration Tests — Test flow end-to-end. Misalnya: buat user, login, buat order, bayar. Lebih lambat tapi worth it untuk catch regression bugs.
Split layer ini jadi separate jobs di GitHub Actions supaya lo bisa parallel execution. Kalau lint fail, lo tau dalam 30 detik — nggak perlu nunggu 5 menit test selesai.
Monitoring Post-Deployment
Deploy bukan akhir — lo perlu tau apakah deploy-nya successful. Setelah deploy, pipeline jalankan health check: tunggu 30 detik, lalu hit endpoint health. Kalau status bukan 200, pipeline fail dan lo dapet notifikasi. Gue pake Telegram notification yang kirim pesan ke personal chat kalau deploy gagal. Ini saved gue berkali-kali dari undetected downtime.
Kesimpulan
CI/CD dengan GitHub Actions itu investment yang langsung ROI-nya terasa. Lo nggak cuma hemat waktu deployment (dari 30 menit ke 5 menit), tapi juga ngilangin stress "aduh jangan sampai salah deploy." Mulai dari yang simpel: test + deploy via SSH. Setelah nyaman, tambahin health check, notification, dan zero-downtime strategy.
Baca juga: Menguasai Docker untuk DevOps untuk setup containerized deployment, atau Hardening SSH Server untuk amankan akses deployment lo.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬