CI/CD & GitHub Actions

backend-go memakai dua workflow GitHub Actions untuk deploy — satu untuk staging, satu untuk produksi. Keduanya berjalan di self-hosted runner (bukan GitHub-hosted), dan memakai pola git reset --hard + rebuild + restart service.

Overview

Self-hosted runner

Runner bukan GitHub-hosted (ubuntu-latest), tapi self-hosted yang terdaftar di server Dazo. Runner ini punya akses sudo untuk:

• systemctl restart — restart systemd service (Go API)
• pm2 restart / pm2 start — restart Node engine workers
• git fetch + git reset --hard — pull code ke server

Label runner

Variabel GitHub (repo Settings → Secrets and variables → Actions)

Workflow memakai repository variables (bukan secrets) untuk path:

Workflow 1 — Staging (deploy_staging.yml)

Trigger: push ke staging branch. Satu job deploy.

Langkah-langkah

1. Checkout repository
   └─ actions/checkout@v3

2. Set PATH for Go
   └─ echo "PATH=$PATH:/usr/local/go/bin" >> $GITHUB_ENV

3. Build Go application
   ├─ cd $PROJECT_DIR_DEVELOPMENT
   ├─ git fetch --all
   ├─ git reset --hard origin/staging     # DESTRUCTIVE — perubahan server hilang
   ├─ go mod tidy
   ├─ go build -o dazodev main.go          # binary: dazodev
   └─ cd engine/ && npm i                  # Node engine install

4. Check & Restart Service DazoDev
   ├─ if systemctl is-active --quiet dazodev:
   │   └─ systemctl restart dazodev
   └─ else: systemctl start dazodev
   └─ systemctl status dazodev --no-pager

5. Check & Restart Service Engine
   ├─ cron=($SERVICE_NAME_DEV)            # array dari vars
   └─ for cron_name in "${cron[@]}":
       ├─ if pm2 describe "$cron_name":
       │   └─ pm2 restart "$cron_name"
       └─ else: pm2 start "$PROJECT_DIR_PRODUCTION/engine/$cron_name.js" --name "$cron_name"

Karakteristik staging

• Satu mesin — Go API + Node engine di server yang sama
• Binary: dazodev (bukan dazo)
• Service name: dazodev (systemd)
• Tidak ada deploy untuk engine/ terpisah — npm i jalan inline

Workflow 2 — Produksi (deploy_production.yml)

Trigger: push ke v3 branch. Dua job paralel di host berbeda.

Job 1: deploy_api — host [self-hosted, production, api]

1. Checkout repository
   └─ actions/checkout@v3

2. Set PATH for Go
   └─ echo "PATH=$PATH:/usr/local/go/bin" >> $GITHUB_ENV

3. Build Go application
   ├─ cd $PROJECT_DIR_PRODUCTION
   ├─ git fetch --all
   ├─ git reset --hard origin/v3          # DESTRUCTIVE
   ├─ go mod tidy
   └─ go build -o dazo main.go            # binary: dazo

4. Check & Restart Service Dazo
   ├─ if systemctl is-active --quiet dazo:
   │   └─ systemctl restart dazo
   └─ else: systemctl start dazo
   └─ systemctl status dazo --no-pager

Job 2: deploy_cron — host [self-hosted, production, cron]

1. Fetch Latest Repository
   ├─ cd $PROJECT_DIR_CRON_PRODUCTION
   ├─ git fetch --all
   └─ git reset --hard origin/v3          # DESTRUCTIVE — tidak ada go build di host ini

2. Check & Restart Service Engine
   ├─ cron=($SERVICE_NAME_PROD)
   └─ for cron_name in "${cron[@]}":
       ├─ if pm2 describe "$cron_name":
       │   └─ pm2 restart "$cron_name"
       └─ else: pm2 start "$PROJECT_DIR_PRODUCTION/engine/$cron_name.js" --name "$cron_name"

Perbandingan staging vs produksi

systemd service

Go API dikelola via systemd:

Pola restart (digunakan di workflow)

if sudo systemctl is-active --quiet dazo; then
    sudo systemctl restart dazo
else
    sudo systemctl start dazo
fi
sudo systemctl status dazo --no-pager

Logik: jika service sudah running, restart. Jika belum (server baru / setelah crash), start. Tidak ada enable — service tidak auto-start saat boot kecuali di-setup terpisah.

PM2 service (Node engine)

Node engine dikelola via PM2. Workflow loop melalui daftar service names dari vars.SERVICE_NAME_*:

cron=($SERVICE_NAME_PROD)          # array dari GitHub vars
for cron_name in "${cron[@]}"; do
    if sudo pm2 describe "$cron_name" > /dev/null 2>&1; then
        sudo pm2 restart "$cron_name"
    else
        sudo pm2 start "$PROJECT_DIR_PRODUCTION/engine/$cron_name.js" --name "$cron_name"
    fi
done

Service names (contoh, dari vars.SERVICE_NAME_PROD)

Yang tidak ada (gap)

Setup server baru

Untuk menjalankan workflow di server baru, yang harus tersedia:

1. Self-hosted runner terdaftar dengan label yang sesuai (staging, production,api, production,cron)
2. Go terinstall di /usr/local/go/bin (lihat Set PATH for Go step)
3. systemd unit — dazo.service (produksi) / dazodev.service (staging). Tidak ada template di repo.
4. PM2 terinstall + semua cron_*.js sudah pernah di-start manual sekali (hindari bug #27)
5. Repo sudah ter-clone di path yang sesuai ($PROJECT_DIR_*)
6. handlers/environtment.go — gitignored, harus dibuat manual dengan konstanta yang sesuai environment. Lihat Environment.
7. .env — GO_ENV=production + kredensial. JWT_SECRET harus sama dengan dazoapp.
8. Node.js terinstall untuk npm i di engine
9. MongoDB dapat diakses dari host API
10. Redis dapat diakses dari host cron (untuk BullMQ)

Monitoring deploy

Cek status deploy:

1. GitHub repo → Actions tab → lihat workflow run
2. Di server: systemctl status dazo / pm2 status
3. Log: journalctl -u dazo -f (systemd) / pm2 logs (Node engine)
4. Health: curl http://localhost:8081/ — harus balas {"Dazo":"App"}

Langkah berikutnya

• Deployment — checklist sebelum push, alur operasi git
• Environment — .env + handlers/environtment.go
• Local Development — cara jalankan lokal
• Tech Debt — bug #27 (PM2 first-start)