Pengenalan Cepat

Untuk tim Go Fiber, tantangan utama adalah memastikan linting, testing, build, dan release dijalankan konsisten sebelum kode masuk ke produksi. Artikel ini langsung menjelaskan bagaimana menyusun pipeline CI/CD yang menggabungkan golangci-lint, caching modul Go, strategi tes paralel/sekuensial, serta release otomatis berbasiskan semantic versioning dan observabilitas.

Dengan pendekatan ini, Anda mendapatkan feedback cepat di setiap push dan bisa mengotomatiskan publikasi binary maupun container, sambil menjaga keamanan secret di runner.

Desain Pipeline CI/CD Untuk Go Fiber

Pada level tinggi, pipeline terbagi menjadi linting, testing (unit/integrasi), build, dan release. Urutan ini memastikan kualitas sebelum artefak diproduksi. Gunakan GitHub Actions atau GitLab CI yang support job dependencies dan caching.

Linting dengan golangci-lint

Linting pertama yang dijalankan menghindari debug berulang di tahap berikutnya. golangci-lint menangani banyak pemeriksaan sekaligus. Konfigurasikan .golangci.yml untuk menyesuaikan rule (misal, disable linters yang tidak relevan agar false positive berkurang).

Setelah checkout, pastikan modul dan dependensi di-cache agar lint berjalan cepat.

Caching Modul Go

Cache modul menghindari unduhan ulang. Gunakan actions/cache (GitHub Actions) dengan key yang termasuk ${{ hashFiles('**/go.sum') }}. Cache path standar adalah ${{ env.GOMODCACHE }} (biasanya $GOMODCACHE). Contoh key:

key: go-mod-cache-${{ runner.os }}-${{ hashFiles('**/go.sum') }}

Cache tidak hanya meningkatkan kecepatan lint/test, tetapi juga mengurangi kegagalan akibat registry go yang tidak stabil.

Strategi Pengujian: Paralel dan Sequential

Pengujian unit cepat bisa dijalankan paralel, sedangkan integrasi yang butuh dependensi eksternal lebih aman dijalankan sekuensial atau di job terpisah.

  • Unit Test Paralel: Gunakan go test ./... -short di job parallelized (misalnya matrix job untuk beberapa versi Go) untuk mendapatkan coverage luas dengan cepat.
  • Integrasi/End-to-End Sekuensial: Job ini bisa membutuhkan resource tambahan (database, Redis). Jalankan setelah lint/test unit berhasil dan pastikan dependency service dikelola via service container.

Pengaturan job dependency (needs di GitHub Actions) memastikan integrasi tidak berjalan sebelum unit test selesai, tapi unit test bisa memanfaatkan matrix untuk paralel antar versi Go.

Contoh Pipeline GitHub Actions

Berikut cuplikan YAML yang mencakup lint, test, build, dan release:

name: ci-cd-fiber
on:
  push:
    branches: [main]
  pull_request:
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Cache Go modules
        uses: actions/cache@v4
        with:
          path: ${{ env.GOMODCACHE }}
          key: go-mod-cache-${{ runner.os }}-${{ hashFiles('**/go.sum') }}
      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.x'
      - name: golangci-lint
        run: golangci-lint run ./...
  test:
    needs: lint
    runs-on: ubuntu-latest
    strategy:
      matrix:
        go-version: ['1.22']
    steps:
      - uses: actions/checkout@v4
      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: ${{ matrix.go-version }}
      - name: Cache modules
        uses: actions/cache@v4
        with:
          path: ${{ env.GOMODCACHE }}
          key: go-mod-cache-${{ runner.os }}-${{ hashFiles('**/go.sum') }}
      - name: Run unit tests (parallelizable)
        run: go test ./... -short
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build binary
        run: go build -o bin/app ./cmd/app
  release:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref_type == 'branch' && github.ref == 'refs/heads/main'
    steps:
      - name: Publish container
        run: | 
          echo "Placeholder: Build dan push image"

Jumlah job bisa disesuaikan, misalnya menambahkan job release container setelah proses build sukses.

Release Otomatis dan Semantic Versioning

Untuk release yang konsisten, gunakan semantic versioning. Pilih pendekatan otomatis: misalnya job release membuat tag berdasar pola conventional commits (patch/minor/major) atau membaca file CHANGELOG.md.

Langkah umum release:

  1. Job release membaca git describe --tags --abbrev=0 untuk versi terakhir.
  2. Menentukan level versi dari commit message atau file release note.
  3. Membuat tag baru dan push ke remote.
  4. Menggunakan tag untuk memicu publikasi binary (Go build) atau container ke registry.

Saat membuat tag/push, jangan lupa setup runner secret seperti GITHUB_TOKEN atau DOCKERHUB_TOKEN sehingga credential tidak terlihat di log.

Publikasi Binary/Container dan Observabilitas

Anda bisa mempublikasikan hasil build sebagai binary release dengan GitHub Releases atau container registry (Docker/OCI). Job release harus:

  • Menggunakan credential aman (secrets tersimpan di repository/organization).
  • Mencatat metadata: hash binary, versi, changelog ringkas.
  • Mengirim notifikasi ke kanal chat atau email.

Untuk observabilitas, simpan artifact log, gunakan badge status pipeline, dan kirim notifikasi (misalnya lewat curl ke webhook Slack). Dokumentasikan steps release di README agar tim tahu apa yang terjadi di setiap tag.

Keamanan Secret dan Debugging Pipeline

Simpan credential seperti token registry di secret manager runner (GitHub Secrets/GitLab CI Variables). Jangan print secret di log, gunakan variabel.

Jika pipeline gagal:

  1. Periksa log job, fokus pada step terakhir yang gagal.
  2. Pastikan cache tidak korup dengan menghapus cache key (misalnya: rerun tanpa cache).
  3. Validasi dependency Go dengan go mod tidy dan go test lokal.
  4. Untuk failure release, cek apakah runner memiliki hak push/tag.

Gunakan job failure notification untuk memberitahu tim melalui Slack/email. Observabilitas pipeline mencakup badge status dan log artifacts.

Penutup

Membangun pipeline CI/CD Go Fiber yang mencakup lint, testing, build, dan release otomatis memang membutuhkan konfigurasi tepat, tetapi hasilnya adalah feedback cepat dan rilis yang konsisten. Terapkan caching modul, pisahkan tes paralel/sekuensial, gunakan semantic versioning untuk release, dan pastikan observabilitas serta keamanan secret. Dengan fondasi ini, tim bisa merilis feature dan perbaikan lebih percaya diri.