Belajar GitHub Actions - Automated Release Management & Semantic Versioning

#Pendahuluan

Di episode 17 kita memasang environment protection rules dan approval gateway. Semua pengamanan itu akhirnya bermuara pada satu momen penting: rilis. Menentukan versi manual seperti v1.2.3 lalu v1.2.4 sering salah hitung, tidak konsisten antar developer, dan membuat changelog menumpuk tak terkontrol. Di episode ini kita menyerahkan penomoran versi, changelog, dan pembuatan GitHub Release sepenuhnya kepada otomasi.

Di episode ini kita membahas:

1. Konsep Semantic Versioning (SemVer) dan Conventional Commits.
2. Otomasi penomoran versi dengan release-please dan semantic-release.
3. Workflow rilis yang membuat GitHub Release beserta changelog dan artifact.

#Semantic Versioning: Bahasa Penamaan Versi yang Disepakati

SemVer memakai format MAJOR.MINOR.PATCH. Analoginya: MAJOR seperti generasi mobil — naik dari generasi 1 ke 2 bisa jadi mesinnya berubah total; MINOR seperti tambahan fitur pada generasi yang sama; PATCH seperti perbaikan kecil pada fitur yang sudah ada. Nomor ini bukan hiasan; ia memberi tahu konsumen seberapa "berbahaya" update tersebut bagi mereka.

Kalau versi salah naik, konsumen bisa kecewa. Menaikkan MAJOR tanpa alasan memaksa mereka meninjau ulang seluruh API; melewatkannya membuat upgrade diam-diam merusak aplikasi mereka.

#Conventional Commits: Sumber Kebenaran Penomoran Versi

Otomasi butuh "umpan" yang bisa dibaca mesin. Conventional Commits adalah konvensi format commit message yang mengekspos jenis perubahan lewat prefix:

Contohnya feat: tambah endpoint healthcheck, fix: perbaiki memory leak pada worker, dan feat!: ganti format response API. Karena prefix inilah yang dibaca tool versioner, disiplin commit message menjadi prasyarat mutlak. Tanpa itu pipeline akan "tuli" terhadap perubahan kode dan versi tidak pernah naik.

#Dua Tool Paling Populer: release-please vs semantic-release

Dua tool yang dominan di ekosistem: release-please (dari Google) dan semantic-release (komunitas). Keduanya membaca Conventional Commits, menghitung versi berikutnya, dan menulis changelog. Perbedaannya pada gaya kerja:

release-please membuka pull request berisi perubahan file CHANGELOG.md dan kenaikan versi di manifest. Setelah PR itu di-merge, ia membuat tag dan GitHub Release — manusia tetap memegang kendali kapan rilis terjadi. semantic-release sebaliknya: begitu kode masuk main, ia langsung menandai versi dan merilis. Cocok untuk tim yang ingin otomasi penuh tanpa review tambahan.

#Workflow Rilis Otomatis dengan release-please

Workflow berikut dijalankan setiap push ke main. Pada push commit fitur, ia membuat atau memperbarui Release PR; pada push hasil merge Release PR, ia menerbitkan tag dan GitHub Release:

name: Release Automation
 
on:
  push:
    branches: [main]
 
permissions:
  contents: write
  pull-requests: write
 
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - name: Jalankan release-please
        uses: google-github-actions/release-please-action@v4
        with:
          release-type: node
          token: ${{ secrets.GITHUB_TOKEN }}

Yang perlu diperhatikan:

• permissions: contents: write dan pull-requests: write dibutuhkan untuk membuat tag, release, dan Release PR.
• release-type: node menyesuaikan perilaku untuk project Node.js; tersedia juga python, go, java, dan simple.
• Action memakai token dari context secrets.GITHUB_TOKEN, sehingga semua perubahannya teraudit sebagai bagian dari repositori.

Siklus kerjanya: developer merge fitur → action membuat "chore(main): release v1.1.0" PR → tim review → PR di-merge → action mendeteksi PR rilisnya tergabung → membuat tag v1.1.0 dan GitHub Release. Hasilnya, rilis selalu didokumentasikan dan mudah ditelusuri.

#Menempelkan Artifact pada GitHub Release dengan softprops

Untuk binary, paket instalasi, atau aset lain, softprops/action-gh-release@v2 menempelkan file ke release. Workflow ini dipicu oleh tag berprefix v dan mengunggah hasil build:

name: Attach Release Assets
 
on:
  push:
    tags: ['v*']
 
permissions:
  contents: write
 
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout kode
        uses: actions/checkout@v4
 
      - name: Build artifact
        run: npm ci && npm run build
 
      - name: Buat/update GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          files: dist/*.zip
          generate_release_notes: true

Penjelasan:

• generate_release_notes: true membuat GitHub menyusun release notes dari commit yang digabung sejak rilis sebelumnya.
• files: dist/*.zip melampirkan semua file zip di folder dist; bisa juga berupa array glob.
• Event tags: ['v*'] membuat workflow ini hanya berjalan saat tag v dibuat, sehingga tidak pernah memicu rilis ganda.

Pola produksi yang umum: release-please membuat tag dan release, lalu workflow bertrigger tag menempelkan artifact ke release yang sudah ada. Keduanya berjalan berurutan tanpa saling menimpa.

#Penutup

Di episode ini kita mengotomasi release management & semantic versioning:

• SemVer (MAJOR.MINOR.PATCH) memberi bahasa versi yang dipahami mesin dan manusia.
• Conventional Commits menjadi sumber kebenaran penentuan versi berikutnya.
• release-please memakai Release PR; semantic-release rilis langsung dari main.
• Workflow pada push main menghasilkan tag dan GitHub Release otomatis.
• softprops/action-gh-release menempelkan artifact ke release yang dipicu tag.

Pipeline produksi yang baik bukan hanya berjalan mulus — ia juga harus mudah ditelusuri saat gagal. Di episode 19 kita membahas troubleshooting, debugging, dan pengembangan custom action, termasuk membuka debug logging dan masuk ke runner lewat SSH. Sampai jumpa!