Belajar Semantic Release - Sejarah, Latar Belakang & Mengapa Menggunakan Semantic Release

#Pendahuluan

Di episode 0 kita menyiapkan environment: Git, Node.js, VS Code, dan GitHub CLI. Sekarang kita berhenti sejenak untuk memahami kenapa semua alat itu diperlukan. Pertanyaan besarnya: mengapa release masih dikerjakan manual, padahal proses itu membuang waktu dan rawan error?

Sejarahnya, release selalu menjadi titik paling menegangkan dalam siklus pengembangan. Versi bisa lupa dinaikkan, changelog bisa meleset dari kenyataan, dan tag bisa tertinggal. Semantic-release lahir justru untuk menghapus drama itu: dengan mengubah riwayat commit menjadi data, mesin bisa menentukan versi, menulis changelog, dan merilis tanpa campur tangan manusia.

#Pembahasan Utama

#Masalah Release Manual

Ada empat pekerjaan manual yang harus diulang setiap kali rilis:

• Menentukan versi: menaikkan major, minor, atau patch? Sering jadi bahan perdebatan.
• Menulis changelog: mengingat semua perubahan sejak rilis terakhir.
• Publish: mengunggah artifact atau package ke registry.
• Tagging: membuat tag git seperti v1.2.3 dan memastikannya ter-push.

Masing-masing punya celah error. Versi bisa lupa dinaikkan, changelog bisa tidak lengkap, dan tag bisa salah posisi — biasanya baru ketahuan saat user membandingkan versi yang beredar.

$ npm version patch
$ npm run build
$ npm publish
$ git tag v1.2.3
$ git push --tags
$ # changelog? eh, lupa ditulis...

Semua langkah mengandalkan memori dan kedisiplinan tim. Satu langkah terlewat, hasilnya adalah versi yang tidak konsisten dengan kenyataan.

#Bagaimana Conventional Commits Mengubah Segalanya

Solusinya bukan mengingat lebih keras, melainkan membuat riwayat commit bisa dibaca mesin. Dengan format commit yang baku, mesin bisa menyimpulkan jenis perubahan secara otomatis: feat menaikkan minor, fix menaikkan patch, dan BREAKING CHANGE: menaikkan major.

feat: tambahkan halaman login
fix: perbaiki validasi email
chore: update dependensi keamanan
BREAKING CHANGE: ganti API auth

Karena commit bersifat kanonik dan permanen, changelog tidak lagi bergantung ingatan manusia — ia diturunkan ulang dari riwayat setiap kali rilis. Changelog yang sama akan konsisten dihitung ulang kapan pun, oleh siapa pun, di mesin mana pun.

#Perbandingan: Manual vs semver-script vs Semantic Release

semver-script yang naik patch terus-menerus menghasilkan 1.0.0, 1.0.1, 1.0.2 padahal ada fitur besar baru — versinya jadi kebohongan. Semantic-release menghitung versi berdasarkan dampak perubahan, bukan urutan rilis.

#Evolusi: dari Checklist ke Otomatisasi

Pola pikirnya berubah dari "menjalankan checklist" menjadi "menyusun sistem". Checklist mengandalkan orang yang patuh; sistem mengandalkan aturan yang otomatis. Perbedaan filosofinya kira-kira begini:

# era manual: 5 langkah, 5 peluang salah
1. cek package.json          -> naikkan versi manual
2. baca git log              -> tulis changelog
3. jalankan build            -> pastikan sukses
4. publish ke registry       -> jangan lupa token
5. git tag + push --tags     -> jangan lupa push
 
# era otomatis: 1 perintah, 0 keputusan manual
npx semantic-release

Perhatikan bagaimana setiap langkah era manual membawa keputusan subjektif: versi berapa, changelog format apa, tag mana yang benar. Era otomatis memindahkan seluruh keputusan itu ke konfigurasi yang bisa di-review, diuji, dan divalidasi sekali — lalu dipakai selamanya.

Semantic-release sendiri lahir dari kenyataan bahwa tim besar di dunia nyata tidak bisa disiplin manual dalam skala panjang. Ia dipakai oleh ribuan project open-source sebagai contoh nyata bahwa otomatisasi versi berjalan stabil di lingkungan yang benar-benar produksi.

#Manfaat Nyata untuk Tim

Ketika proses rilis otomatis, dampaknya merambat ke seluruh alur kerja tim:

• Developer tidak pusing versi — cukup menulis commit berformat, versi dihitung sendiri.
• Changelog selalu akurat — lahir dari commit, bukan dari ingatan orang yang release minggu lalu.
• Release bersifat audit-able — setiap versi menunjuk ke commit spesifik, mudah di-reproduce.
• Rollback lebih mudah — versi sebelumnya tinggal ditarik dari registry karena tag dan release tercatat rapi.
• Onboarding lebih cepat — kontributor baru tidak perlu menghafal prosedur rilis rahasia.

#Kapan Semantic Release Kurang Tepat?

Jujur dulu: tidak semua proyek butuh ini. Proyek kecil satu orang yang belum punya user eksternal mungkin cukup dengan tag manual. Semantic-release baru terasa nilainya ketika ada user yang bergantung pada versi, changelog harus dipertahankan, dan lebih dari satu orang menyentuh branch yang sama. Di titik itu, menyerahkan versi kepada mesin adalah penghematan besar.

npx semantic-release
# analisis commit -> hitung versi -> tulis changelog
# -> buat tag -> publish -> buat GitHub Release
# semua dari riwayat commit yang berstruktur

Perhatikan: tidak ada prompt konfirmasi, tidak ada keputusan subjektif. Konfigurasi di release.config.cjs menentukan semuanya, dan riwayat commit adalah satu-satunya input.

#Penutup

Pada episode 1 ini kalian telah memahami:

• Empat pekerjaan manual release (versi, changelog, publish, tag) semuanya rentan error.
• Conventional Commits mengubah riwayat commit menjadi data yang bisa dianalisis otomatis.
• Versi dihitung dari dampak perubahan, bukan dari urutan rilis.
• semantic-release menyatukan semuanya dalam satu perintah di CI.

Di episode 2 kita akan membedah konsep dasar dan arsitektur: aturan semver, cara commit analyzer bekerja, serta bagaimana plugin pipeline menyusun sebuah rilis dari awal sampai akhir. Sampai jumpa di episode 2!