Belajar Semantic Release - Protected Branches & PR Policies

#Pendahuluan

Di episode 12 kita membahas keamanan workflow, dari least privilege hingga proteksi secrets. Kini pertimbangkan sebuah kenyataan: begitu release berjalan otomatis, satu commit buruk di main langsung menjadi versi produksi yang dirilis. Di sinilah branch protection menjadi garda terakhir sebelum kode menyentuh rilis.

Branch protection rules adalah gerbang yang memaksa setiap perubahan melewati PR, status check, dan review sebelum masuk ke branch penting. Untuk pipeline semantic-release, ini bukan sekadar praktik baik — melainkan syarat mutlak agar otomatisasi tidak menjadi bumerang.

#Mengapa main dan rc Wajib Dilindungi

Dua branch paling sensitif di repository kita:

• main — sumber rilis stable; setiap merge di sini berpotensi menghasilkan versi baru 1.2.3.
• staging (alias rc) — sumber rilis release candidate 1.2.3-rc.N yang diuji di environment staging.

Karena kedua branch ini memicu release otomatis, mereka harus diatur dengan aturan paling ketat. Branch feature/* boleh longgar — cukup pipeline hijau — tetapi main dan rc wajib lulus semua gerbang.

#Walkthrough Branch Protection di GitHub

Langkahnya melalui antarmuka GitHub:

1. Buka Settings → Branches → Add branch protection rule.
2. Isi Branch name pattern dengan main.
3. Centang Require a pull request before merging dan set Required number of approvals misal 1–2.
4. Centang Require status checks to pass before merging.
5. Centang Require branches to be up to date before merging agar status check berjalan terhadap commit terbaru.
6. Ulangi untuk pola staging.

Untuk tim yang ingin menerapkan aturan yang sama lintas repository, GitHub juga menyediakan rulesets (Settings → Rules → Rulesets) yang bisa dikelola terpusat dan mendukung konfigurasi berbasis kode.

#Require Status Checks: Lint, Build, Dry Run

Status check di GitHub diambil dari nama job di workflow CI yang berjalan pada pull request. Nama inilah yang kalian centang di daftar required status checks:

name: CI
 
on:
  pull_request:
    branches: [main, staging]
 
permissions:
  contents: read
 
jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: bun run lint
 
  build:
    name: Build
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: bun run build
 
  dry-run:
    name: Dry Run
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: npx semantic-release --dry-run --no-ci

Di form branch protection, centang Lint, Build, dan Dry Run sebagai required checks. Kehadiran check Dry Run sangat penting: ia memvalidasi bahwa commit-commit di PR tersebut akan menghasilkan versi yang benar, changelog yang valid, dan tidak ada error konfigurasi — tanpa benar-benar merilis apa pun. Kalian bisa mencoba perintah yang sama secara lokal dengan npx semantic-release --dry-run --no-ci.

#Mandatory Reviewers

Selain pipeline otomatis, review manusia tetap wajib. Atur:

• Require a pull request before merging — memaksa semua perubahan lewat PR.
• Required number of approvals — minimal 1 reviewer untuk PR kecil, 2 untuk kode sensitif.
• Require review from Code Owners — jika ada file CODEOWNERS, perubahan pada bagian tertentu otomatis menunjuk reviewer.
• Dismiss stale reviews — review lama dibatalkan otomatis ketika ada commit baru.

#Menerapkan Rule Lewat Kode

Branch protection juga bisa diterapkan secara reproducible memakai GitHub CLI dengan file JSON sebagai input:

{
  "required_status_checks": {
    "strict": true,
    "contexts": ["Lint", "Build", "Dry Run"]
  },
  "required_pull_request_reviews": {
    "required_approving_review_count": 1
  },
  "enforce_admins": true
}

gh api repos/devnull/learn-semantic-release/branches/main/protection \
  --method PUT \
  --input protection.json

Pendekatan ini membuat konfigurasi keamanan bisa di-review seperti kode biasa dan dipakai ulang di repository lain.

#Strategi Merge dan Dampaknya ke Conventional Commits

Cara PR di-merge menentukan bentuk history yang dibaca semantic-release. Tiga opsi utama di tombol merge GitHub:

Sebaliknya, merge commit menyimpan pesan per-commit asli sehingga analisis lebih akurat, tetapi ada risikonya: jika komitmen di dalamnya tidak konsisten, versi bisa naik lebih dari sekali untuk satu PR. Banyak tim mengkombinasikan squash-merge dengan aturan "judul PR harus valid" untuk mendapatkan history yang bersih sekaligus analisis yang bisa diprediksi.

Untuk memaksa kebijakan ini di tingkat repository, atur Settings → Allow merge commits / Allow squash merging / Allow rebase merging dan matikan opsi yang tidak diinginkan.

#Penutup

Rekap episode 13:

• Lindungi main dan staging (rc) dengan branch protection rule yang ketat.
• Require status checks Lint, Build, dan Dry Run — nama job harus sinkron.
• Mandatory reviewers dengan jumlah approval dan stale review dismissal.
• Pilih strategi merge yang sesuai: squash-merge butuh judul PR valid, merge commit menjaga detail per-commit.
• Branch protection dan ruleset juga bisa diterapkan secara terpusat dan berbasis kode.

Dengan gerbang yang kuat, rilis yang keluar sudah teruji dua lapis: otomatis dan manusia. Episode berikutnya kita membahas Audit, Changelog & Release Notes — bagaimana semantic-release menulis changelog otomatis dan menghubungkannya ke GitHub Releases. Sampai jumpa!