Belajar Semantic Release - Release Monitoring & Post-release Checks

#Pendahuluan

Di episode 17 pesan commit sudah disiplin dan release berjalan otomatis. Tetapi rilis bukanlah akhir pekerjaan — rilis adalah awal dari pengawasan. Sebuah versi yang dipublish belum tentu sehat; kesehatan harus dibuktikan.

Episode ini membahas release monitoring & post-release checks: observability lewat tag versi dan dashboard, validasi otomatis setelah publish, dan kesiapan rollback ketika versi ternyata bermasalah.

#Observability: Tag Versi & Dashboard

Setiap rilis meninggalkan artefak yang bisa dipantau:

Tag Git — v1.4.0, v1.4.0-rc.2. Daftar tag adalah kronologi rilis tercepat; git tag --sort=-v:refname menampilkan versi terbaru.
GitHub Releases — halaman berisi changelog, diff, dan asset tiap versi.
Registry — versi yang terpublish di npm atau private registry.
Dashboard — agregasi data rilis (misal BigQuery dari webhook, atau dashboard sederhana berbasis GitHub API) untuk menjawab "berapa rilis minggu ini" dan "berapa yang gagal".

Daftar versi terbaru dari tag

git tag --sort=-v:refname | head -5
v1.6.2
v1.6.1
v1.6.0

Untuk tim yang butuh otomatisasi, webhook GitHub bisa mengirim event release ke channel komunikasi atau dashboard — dengan plugin notifikasi seperti @semantic-release/slack atau kait Discord lewat successCmd dari @semantic-release/exec.

#Memantau Keberhasilan Publish

Kegagalan publish tidak selalu terlihat jelas. Indikator yang perlu dipantau:

Exit code pipeline release — non-zero berarti ada step yang gagal.
Versi di registry sesuai dengan versi yang diklaim changelog.
GitHub Release dan tag muncul — bukan hanya sukses publish ke npm.
Alert otomatis saat pipeline gagal atau versi tidak ditemukan.

Pola yang direkomendasikan: pisahkan job "release" dan job "validasi pasca-release" yang berjalan berurutan dengan needs. Jika validasi gagal, tim langsung tahu sebelum user melaporkan.

#Job Validasi Pasca-release

Workflow berikut merilis ke npm lalu memvalidasi bahwa versi benar-benar terpublish dan layanan sehat:

release.yml dengan validasi pasca rilis

name: Release
 
on:
  push:
    branches: [main]
 
permissions:
  contents: write
 
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
  post-release-check:
    runs-on: ubuntu-latest
    needs: release
    steps:
      - name: Cek versi terpublish di registry
        run: |
          VERSION=$(curl -s https://registry.npmjs.org/@devnull/learn-semantic-release/latest \
            | jq -r .version)
          echo "Versi terpublish: $VERSION"
          test -n "$VERSION"
      - name: Smoke test endpoint produksi
        run: |
          curl -sf https://api.example.com/health | jq -e '.status == "ok"'

Yang terjadi:

Job release mempublish versi baru lewat semantic-release.
Job post-release-check menunggu release selesai dengan needs: release, lalu mengambil versi terbaru dari registry dengan curl dan memvalidasi bahwa ia ada.
Smoke test memanggil endpoint kesehatan produksi; jika respons bukan status ok, job gagal dan tim menerima alert dari GitHub.

Untuk skenario yang lebih ketat, validasi juga bisa mengunduh tarball versi tersebut dan menjalankan uji pemasangan bersih (npm install di container baru).

Tip

Uji job validasi dengan dryRun: jalankan npx semantic-release --dry-run --no-ci di branch PR, lalu pastikan perintah validasi menangkap nomor versi yang sama dengan yang diprediksi changelog. Ini menjaga script validasi tidak mengecoh di production.

#Rollback Readiness

Rencana rollback harus diputuskan sebelum insiden, bukan saat insiden. Beberapa strategi:

Versi baru menggantikan versi rusak — terapkan fix dan biarkan semantic-release menaikkan versi (patch). Paling sederhana dan umum.
Deprecate versi — untuk npm, npm deprecate paket@versi "mengandung bug" menandai versi rusak tanpa menghapusnya.
Revert commit — git revert <sha> membalik perubahan; karena revert menghasilkan commit revert:, semantic-release akan menerbitkan versi baru otomatis.
Rollback deployment — pada level infrastruktur, kembali ke image atau tag sebelumnya, misal v1.5.0.

Warning

Jangan pernah menghapus tag versi yang sudah terpublish atau melakukan force push untuk "menghilangkan" versi yang salah. Tag yang terhapus membuat riwayat rilis tidak konsisten, memutus tautan GitHub Release, dan merusak semver yang sudah dipakai konsumen. Strategi yang benar: terbitkan versi perbaikan baru atau deprecate versi lama — riwayat tetap utuh dan konsumen selalu bisa naik ke versi yang sehat.

Simulasikan readiness rollback secara berkala: catat komit terakhir per versi, dokumentasikan langkah men-deploy versi sebelumnya, dan pastikan semua image di-tag dengan versi yang sama dengan release.

#Penutup

Rekap episode 18:

Observability release: tag Git, GitHub Releases, registry, dan dashboard.
Job validasi pasca-release memastikan versi benar-benar terpublish dan layanan sehat.
Smoke test dan uji pemasangan bersih menangkap kegagalan sebelum user.
Rollback terbaik adalah versi perbaikan baru; hindari menghapus tag atau menulis ulang history release.
Siapkan dan latih prosedur rollback sebelum insiden terjadi.

Dengan monitoring dan kesiapan rollback, pipeline release kalian tidak hanya otomatis tetapi juga dapat dipercaya. Di episode 19 kita membuka GitOps dan Release Automation — menyelaraskan rilis dengan deployment otomatis berbasis GitOps. Sampai jumpa!