Belajar Semantic Release - Organization Standards & Training

#Pendahuluan

Di episode 19 kita menghubungkan release dengan deployment lewat GitOps. Tapi ada satu bahan bakar yang menentukan segalanya: kualitas commit message. semantic-release hanya sebagus commit yang masuk — bila anggota tim menulis fix: fix bug, analyzer tidak bisa menebak jenis perubahan apa pun dan tidak ada release yang terbit. Konfigurasi terbaik di dunia tidak menolong bila standar tidak didokumentasikan dan diajarkan.

Di episode ini kita membahas:

1. Dokumentasi standar commit message, branching, dan proses release.
2. Onboarding developer baru menuju Conventional Commits.
3. Checklist code review untuk PR dan release.

#Pembahasan Utama

#Standar Dimulai dari Dokumentasi

Aturan yang hanya ada di kepala senior engineer adalah aturan yang tidak pernah dipatuhi. Standar organisasi harus:

• Tertulis di repository, bukan di chat atau slide yang hilang.
• Versioned bersama kode, sehingga ikut ter-review dan ter-update.
• Mudah dicari — satu tempat kanonis, lalu ditautkan dari mana-mana.

Dua dokumen yang paling berdampak: CONTRIBUTING.md untuk kontributor, dan docs/release-process.md untuk siapa pun yang terlibat rilis.

#CONTRIBUTING.md: Bagian Commit Guidelines

Mulailah CONTRIBUTING.md dengan bagian commit guidelines yang tegas. Template minimal:

## Conventional Commits
 
Setiap commit wajib mengikuti spesifikasi Conventional Commits:
 
Format: `type(scope): subject`
 
Type yang digunakan:
 
- `feat` - fitur baru, memicu rilis minor
- `fix` - perbaikan bug, memicu rilis patch
- `perf`, `refactor`, `docs`, `test`, `style`, `chore`, `build`, `ci`, `revert`
 
Aturan khusus:
 
- Breaking change: tulis footer `BREAKING CHANGE:` atau tambahkan tanda seru
  pada subject, contoh: `feat!: drop dukungan Node 16`
- Scope opsional, wajib kata benda singkat: `feat(auth): tambah SSO`
- Subject imperatif, huruf kecil, tanpa titik di akhir
- Body menjelaskan mengapa, bukan apa
 
Baca spesifikasi lengkap di conventionalcommits.org sebelum commit pertama.

Standar yang ditulis seperti ini bisa langsung diterjemahkan menjadi aturan commitlint — sehingga dokumentasi dan enforcement membaca sumber yang sama, tidak menyimpang.

#Mendokumentasikan Model Branching

Bagian kedua dari CONTRIBUTING.md adalah model branching. Tim yang tidak paham ke mana harus push akan membuat kekacauan sendiri:

Aturan tegas yang wajib didokumentasikan:

• Semua perubahan masuk lewat Pull Request, tidak ada push langsung.
• main dan staging dilindungi branch protection.
• Merge staging ke main adalah satu-satunya jalan menuju produksi.
• Branch feature/* dihapus setelah merge.

#Developer Onboarding: Dari Nol ke Commit yang Benar

Onboarding bukan sekadar memberi akses repository. Alur yang bekerja di dunia nyata:

1. Developer membaca CONTRIBUTING.md — jadikan ini bagian dari task pertama.
2. Developer menjalankan instalasi dependensi, lalu husky memasang hook otomatis.
3. commitlint memeriksa setiap commit message; commit yang tidak konvensional ditolak sebelum sempat masuk git history.

Setup commitlint plus husky yang sudah dibahas di episode 3 dan 9 tetap menjadi tulang punggung:

npm install --save-dev @commitlint/cli @commitlint/config-conventional
npx husky init
npx husky add .husky/commit-msg "npx --no -- commitlint --edit $1"
git commit -m "feat: tambah login SSO"

Dengan hook ini, developer belajar dari mesin, bukan dari teguran reviewer. Kesalahan ditangkap sedini mungkin — inilah feedback loop tercepat untuk membangun kebiasaan.

#Checklist Code Review untuk PR dan Release

Review bukan hanya memeriksa kode — ia juga gerbang kualitas untuk release. Checklist yang praktis:

• Commit message mengikuti Conventional Commits dan scope-nya tepat.
• Breaking change didokumentasikan dengan jelas, baik di commit maupun di PR description.
• PR yang mengubah perilaku publik aplikasi dilabeli dan dampaknya disebutkan.
• Hasil dry-run masuk akal: feat menghasilkan minor, fix menghasilkan patch.
• Changelog yang dihasilkan terbaca: setiap entri menjelaskan perubahan nyata, bukan copy-paste judul commit.
• Tidak ada token, password, atau kredensial yang bocor di diff.

Untuk release, tambahkan pemeriksaan pasca-rilis:

• Tag versi terbit sesuai ekspektasi — bukan minor padahal seharusnya major.
• GitHub Release memuat changelog yang benar.
• Image versi itu berhasil dibangun dan ter-deploy ke environment yang tepat.

Review release yang paling efektif dilakukan saat PR di-merge, bukan saat rilis sudah terbit — di situlah keputusan versi benar-benar ditentukan.

#Mendokumentasikan Proses Release

Terakhir, tulis docs/release-process.md supaya tidak ada misteri:

• Kapan rilis terjadi: otomatis saat merge ke staging dan main.
• Siapa yang bertanggung jawab bila rilis gagal di tengah jalan.
• Apa yang harus dicek sebelum rilis ke produksi.
• Langkah rollback: git revert v1.3.0 lalu rilis ulang, atau men-deploy ulang versi sebelumnya.

#Penutup

Di episode ini kita membangun fondasi manusia di atas fondasi mesin:

• Standar tertulis di CONTRIBUTING.md dan docs/release-process.md.
• Model branching didokumentasikan: main stable, staging rc, feature/* sementara.
• Onboarding memanfaatkan commitlint dan husky sebagai guru yang tidak sabar.
• Checklist review mencakup commit, versi, changelog, dan keamanan.

Sekarang satu tim bisa bekerja konsisten. Di episode 21 kita membawa konsistensi itu ke skala yang lebih besar — shared config, reusable workflow, dan strategi monorepo. Sampai jumpa!