Pada proyek modern, tombol release sering menumpuk karena perlu menilai dampak perubahan berkali-kali. Otomasi rilis semantic adalah jawaban praktis: setiap commit yang mengikuti Conventional Commits bisa memicu penentuan tingkat versi, catatan changelog, pembuatan artefak, serta publikasi ke registry (npm/pypi) hanya jika branch utama sudah lolos semua pemeriksaan.

Artikel ini menjelaskan langkah teknis: linting commit, generator changelog otomatis, hingga GitHub Actions yang memverifikasi cabang utama sebelum membuat tag SemVer dan mengunggah rilis. Semua konfigurasi disusun agar praktis digunakan di proyek nyata.

Apa yang membuat pendekatan ini valid?

Konvensi klasik Conventional Commits mencantumkan tipe perubahan (feat, fix, chore) dan indikator perbaikan besar (!), sehingga alat downstream dapat menghitung apakah perubahan itu patch, minor, atau major. Dengan standar ini, tidak perlu manusia menebak versi berikutnya.

Catatan penting: pastikan semua anggota tim sadar bahwa linting commit akan menolak pesan yang tidak sesuai format. Otomasi baru efektif jika inputnya terstandar.

Linting pesan commit

Gunakan commitlint atau alat serupa untuk mencegah commit tidak valid. Tambahkan paket berikut (contohnya dengan npm):

npm install --save-dev @commitlint/config-conventional @commitlint/cli husky

Konfigurasinya:

{
  "extends": ["@commitlint/config-conventional"]
}

Aktifkan Husky untuk hook commit-msg:

npx husky install
npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"

Hasilnya: commit yang tidak mengikuti pola akan ditolak sebelum masuk ke repositori, menjaga kualitas input pipeline release.

Generator changelog dan penentuan versi

Paket seperti semantic-release menggabungkan linting commit untuk menghitung versi baru, membuat changelog, serta mempublikasikan release. Struktur dasar .releaserc:

{
  "branches": ["main"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    ["@semantic-release/changelog", {"changelogFile": "CHANGELOG.md"}],
    "@semantic-release/npm",
    "@semantic-release/github"
  ]
}

Penjelasan:

  • Commit analyzer menentukan apakah kenaikan versi patch/minor/major.
  • Release notes generator membuat ringkasan perubahan berdasarkan jenis commit.
  • Changelog ditulis ke CHANGELOG.md dan bisa dikomit kembali.
  • npm/GitHub plugin menangani publikasi paket dan release GitHub.

Untuk proyek Python, ganti plugin npm dengan @semantic-release/python atau skrip custom yang menggunakan twine setelah versi ditetapkan.

Pipeline GitHub Actions yang aman

Berikut struktur pipeline untuk branch main:

name: Otomasi Rilis Semantic
on:
  push:
    branches: [main]

jobs:
  verify-and-release:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          registry-url: 'https://registry.npmjs.org'
      - name: Install dependencies
        run: npm ci
      - name: Run tests dan lint
        run: npm run lint && npm test
      - name: Semantic release
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

Beberapa poin penting:

  • fetch-depth: 0 memastikan seluruh riwayat git tersedia untuk semantic-release menginspeksi tag sebelumnya.
  • Permissions terbatas mengurangi akses agen CI; hanya paket dan konten yang diperbolehkan.
  • Variabel lingkungan diisi dari Secrets GitHub untuk keamanan token.

Jika proyek Python, ganti langkah setup Node dengan environment Python dan jalankan pip install -r requirements-dev.txt. Gunakan python -m build dan twine upload dalam bagian release jika semantic-release tidak langsung mendukung.

Pengamanan token dan rollback

Simpan token di GitHub Secrets dengan nama jelas, misalnya NPM_TOKEN dan GITHUB_TOKEN. Jangan pernah menampilkan nilai token di log output: misalnya, hindari echo ${{ secrets.NPM_TOKEN }}.

Jika release gagal:

  1. Periksa log GitHub Actions untuk langkah terakhir; biasanya semantic-release memberikan alasan kegagalan (misalnya konflik tag atau kegagalan upload artefak).
  2. Gunakan git tag -d lokal dan git push origin :refs/tags/vX.Y.Z bila tag sudah keluar tapi rilis tidak lengkap.
  3. Perbaiki commit berdasarkan tipe Conventional Commits untuk memicu ulang rilis.

Rollback artefak registry (npm/pypi) umumnya memerlukan versi baru. Jangan paksa versi lama untuk diterbitkan ulang; lebih baik buat patch release baru jika perlu pembatalan sementara.

Tips tambahan

  • Pastikan file CHANGELOG.md dimasukkan ke commit release agar dokumentasi update selalu tersedia.
  • Uji pipeline pertama kali pada cabang staging dengan semantic-release --dry-run untuk melihat output tanpa memodifikasi tag atau publish.
  • Gunakan badge status workflow di README agar tim tahu kapan rilis otomatis aktif.

Kombinasi linting commit, generator changelog, serta GitHub Actions yang memverifikasi branch utama menghasilkan rilis yang konsisten dan dapat direproduksi. Dengan perlindungan token dan langkah rollback siap pakai, proses rilis jadi dapat diandalkan sekaligus aman.