Belajar Semantic Release - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kita sepakat bahwa riwayat commit bisa menjadi sumber kebenaran untuk menentukan versi. Sekarang pertanyaannya bergeser: bagaimana caranya? Jawabannya ada di dua hal yang menjadi fondasi arsitektur semantic-release: Semantic Versioning (SemVer) sebagai bahasa versi, dan commit analyzer sebagai otak yang menerjemahkan commit menjadi keputusan rilis.

Bayangkan semantic-release seperti seorang resepsionis pabrik yang membaca catatan harian para pekerja. Setiap catatan berformat, sehingga ia tahu: "ada fitur baru" berarti nomor seri naik satu tingkat minor, "ada perbaikan bug" naik satu tingkat patch, dan "ada perubahan besar" naik satu tingkat major. Seluruh proses itu ditulis dalam kode, bukan kebijakan lisan.

#Pembahasan Utama

#SemVer: Bahasa Versi

Semantic Versioning memberi arti pada angka versi MAJOR.MINOR.PATCH:

MAJOR: perubahan yang tidak kompatibel ke belakang (breaking).
MINOR: fitur baru yang kompatibel ke belakang.
PATCH: perbaikan bug yang kompatibel ke belakang.

Aturan naiknya versi

1.0.0  -> 1.1.0      (minor: fitur baru)
1.1.0  -> 1.1.1      (patch: perbaikan bug)
1.1.1  -> 1.2.0-rc.1 (prerelease rc)
1.2.0-rc.1  -> 1.2.0 (stable setelah rc lolos)

Prerelease ditulis dengan suffix seperti 1.2.0-rc.1 dan memiliki precedence lebih rendah daripada stable 1.2.0. Sifat ini yang dimanfaatkan branch staging untuk menguji calon rilis sebelum naik ke main.

#Commit Analyzer: Otak Penerjemah

Commit analyzer membaca commit-commit sejak tag rilis terakhir dan menentukan release type: major, minor, patch, atau tidak ada rilis sama sekali.

Commit analyzer menghitung jenis rilis dari jendela commit

v1.0.0 (tag rilis terakhir)
   |
   +-- fix: perbaiki validasi email    -> patch
   +-- feat: tambahkan halaman login   -> minor
   |
v1.1.0 (versi berikutnya)

Versi rilis ditentukan dari jenis commit tertinggi dalam jendela tersebut: satu feat menaikkan minor, satu breaking change menaikkan major. Jika tidak ada feat, fix, atau breaking change, tidak ada rilis baru — changelog, tag, dan publish semuanya dilewati.

#Struktur Pipeline

Rilis yang sehat tidak langsung dipicu begitu commit di-push. Pipeline bertingkat memastikan hanya kode yang lulus verifikasi yang dirilis.

Pipeline yang sehat: lint -> build -> dry run -> release

npm run lint
npm run build
npx semantic-release --dry-run --no-ci
npx semantic-release

Lint dan build menjalankan jaminan kualitas di setiap pull request — sebelum ada yang dirilis.
Dry run memperlihatkan apa yang akan terjadi tanpa efek samping apa pun. Ini jaring pengaman terbaik.
Release hanya berjalan di branch yang diizinkan, menggunakan hasil analisis commit.

#Sembilan Langkah Plugin Pipeline

Setiap plugin mengimplementasikan satu atau lebih langkah. Seluruh rilis mengalir melalui urutan berikut:

Alur langkah pipeline semantic-release

1 verifyConditions
2 analyzeCommits
3 verifyRelease
4 generateNotes
5 prepare
6 publish
7 addChannel
8 success
9 fail

Penjelasan tiap langkah:

verifyConditions: plugin memverifikasi prasyarat — token tersedia, registry bisa diakses, environment benar.
analyzeCommits: commit analyzer menghitung release type dari riwayat commit.
verifyRelease: validasi akhir sebelum versi ditulis, misalnya memastikan release type bukan null.
generateNotes: release-notes-generator menyusun changelog dari commit yang sudah diklasifikasikan.
prepare: plugin menulis versi baru ke file — package.json, CHANGELOG.md, atau artifact lain.
publish: mengunggah hasil rilis — npm publish, atau membuat GitHub Release.
addChannel: menambahkan rilis ke channel, digunakan untuk prerelease di branch tambahan.
success: memberi tahu pihak lain bahwa rilis berhasil, misalnya komentar di PR.
fail: dijalankan ketika ada error, biasanya membuat issue atau laporan kegagalan.

#Plugin Inti

Plugin	Langkah Utama	Tugas Utama
commit-analyzer	analyzeCommits	Menentukan release type dari commit
release-notes-generator	generateNotes	Menyusun changelog
npm	verifyConditions, prepare, publish	Update package.json + publish registry
github	verifyConditions, publish, success, fail	GitHub Release + komentar PR + issue
git	prepare	Commit file hasil prepare + buat tag

Kombinasi git + npm adalah pasangan yang paling sering dipakai: git meng-commit hasil prepare (versi baru di package.json dan CHANGELOG.md) sekaligus membuat tag, lalu npm mempublikasikan package. Repo blog ini memakai kelima plugin inti tersebut — silakan buka release.config.cjs dan bandingkan dengan tabel di atas.

Tip

Sebelum mengaktifkan release sungguhan, biasakan menjalankan npx semantic-release --dry-run --no-ci dulu. Outputnya menunjukkan versi yang akan dibuat, changelog yang akan dihasilkan, dan plugin mana saja yang akan dijalankan — tanpa menyentuh git atau registry.

#Penutup

Pada episode 2 ini kalian telah memahami:

Aturan SemVer: major untuk breaking, minor untuk fitur, patch untuk bug, dengan suffix rc untuk prerelease.
Commit analyzer menentukan release type dari jenis commit tertinggi dalam jendela rilis.
Pipeline sehat: lint, build, dry run, lalu release.
Sembilan langkah plugin pipeline, dari verifyConditions sampai fail.

Di episode 3 kita akan fokus pada bahasa yang dibaca commit analyzer: Conventional Commits — format type(scope): subject, daftar type yang umum, dan cara menandai breaking change. Sampai jumpa di episode 3!