Release Workflow

Kita kini punya semua suku cadang: tag annotated, penomoran SemVer, tag yang bisa dipush. Yang belum ada adalah urutannya — dan justru urutan itulah yang membedakan rilis yang tenang dari rilis yang panik. Meneriakkan “ini sudah 1.2.0!” sambil menambah fitur, lalu menulis changelog seminggu kemudian, adalah resep klasik kekacauan. Bab-bab sebelumnya di section lain telah menunjukkan pola serupa: Strategi Branching menjaga pengembangan, Changelog menjaga dokumentasi. Chapter ini merakit keduanya menjadi alur rilis terstandar — delapan langkah dari pembekuan fitur sampai pengumuman, lalu menjalankannya sungguhan pada sandbox.

Delapan Langkah Alur Rilis #

Langkah	Nama	Perintah kunci
1	Pembekuan fitur (feature freeze)	— keputusan tim, bukan perintah
2	Stabilisasi — hanya perbaikan	`git log v1.1.0..main --oneline`
3	Mutakhirkan CHANGELOG & berkas versi	sunting `CHANGELOG.md`, `VERSION`
4	Commit persiapan rilis	`git commit -m "Siapkan rilis v1.2.0"`
5	Tag annotated	`git tag -a v1.2.0 -m "..."`
6	Push branch dan tag	`git push origin main`, `git push origin v1.2.0`
7	Bangun artefak dari tag	`git archive`
8	Umumkan	GitHub Release / kanal tim

Alurnya membaca dari atas ke bawah, dan setiap langkah punya alasan keluar:

flowchart TD A["1. Pembekuan fitur"] --> B["2. Stabilisasi: hanya perbaikan bug"] B --> C["3. Mutakhirkan CHANGELOG.md dan VERSION"] C --> D["4. Commit persiapan rilis"] D --> E["5. Tag annotated v1.2.0"] E --> F["6. Push main dan tag ke remote"] F --> G["7. Bangun artefak dari tag"] G --> H["8. Umumkan rilis"] B -- "fitur baru muncul? kembali ke langkah 1" --> A

Garisi balik dari stabilisasi ke pembekuan adalah pengaman terpenting: begitu satu fitur baru menyusup setelah pembekuan, seluruh rangkaian sebaiknya diulang — fitur itu belum diperiksa, belum tercatat, dan belum dinomori. Rilis yang disiplin memilih menunda fitur, bukan menunda kehati-hatian.

Demo Nyata: Merilis v1.2.0 #

Sandbox berupa situs toko yang sudah dua kali dirilis — v1.0.0 dan v1.1.0 — dengan remote pusat siap menerima:

bash
mkdir latihan-rilis && cd latihan-rilis
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf '# Toko Berkah\nberanda\n' > situs.md
git add situs.md
git commit -m "Buat halaman beranda"
git tag -a v1.0.0 -m "Rilis pertama"
printf 'keranjang belanja kosong\n' > keranjang.md
git add keranjang.md
git commit -m "Tambah keranjang belanja"
printf 'daftar produk unggulan\n' > produk.md
git add produk.md
git commit -m "Tambah halaman produk"
git tag -a v1.1.0 -m "Rilis fitur belanja"
git init --bare ../toko-pusat.git
git remote add origin ../toko-pusat.git
git push -u origin main
git push origin v1.0.0 v1.1.0

Dua perubahan pasca-v1.1.0 menjadi isi kandidat rilis: satu fitur (kolom pencarian) dan satu perbaikan (tautan rusak). Ini fase stabilisasi — setelah keduanya masuk, tidak ada fitur lain yang diterima:

bash
printf 'daftar produk unggulan\npencarian: tersedia\n' > produk.md
git add produk.md
git commit -m "Tambah kolom pencarian produk"
printf '# Toko Berkah\nberanda\nmenu: beranda | produk\n' > situs.md
git add situs.md
git commit -m "Perbaiki tautan rusak di beranda"

Sebelum membekukan, kita periksa apa saja yang bakal masuk rilis — rentang v1.1.0..main berisi semua commit sejak rilis terakhir:

bash

git log v1.1.0..main --oneline

Output yang Dihasilkan:

text

d18d4e5 Perbaiki tautan rusak di beranda
f88f6b9 Tambah kolom pencarian produk

Dua commit, satu fitur satu perbaikan — pas untuk v1.2.0 menurut aturan SemVer di Semantic Versioning : MINOR naik karena ada fitur baru.

Langkah 3-4: CHANGELOG dan Commit Persiapan #

Rilis mendokumentasikan dirinya. Kita tulis CHANGELOG.md dan VERSION — isian changelognya berasal dari dua commit barusan (format lengkapnya dibedah di chapter berikutnya):

bash
cat > CHANGELOG.md <<'EOF'
# Changelog

Semua perubahan penting pada proyek ini didokumentasikan pada berkas ini.
Format mengikuti Keep a Changelog, dan penomoran versi mengikuti Semantic Versioning.

## [Belum Dirilis]

## [1.2.0] - 2026-10-28

### Added
- Kolom pencarian produk di halaman produk.

### Fixed
- Tautan rusak di halaman beranda.

## [1.1.0] - 2026-10-27

### Added
- Keranjang belanja.
- Halaman produk.

## [1.0.0] - 2026-10-27

### Added
- Halaman beranda.

[Belum Dirilis]: https://github.com/budi-santoso/toko/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/budi-santoso/toko/compare/v1.1.0...v1.2.0
[1.1.0]: https://github.com/budi-santoso/toko/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/budi-santoso/toko/releases/tag/v1.0.0
EOF
printf '1.2.0\n' > VERSION
git add CHANGELOG.md VERSION
git commit -m "Siapkan rilis v1.2.0"

Output yang Dihasilkan:

text
[main e910f52] Siapkan rilis v1.2.0
 2 files changed, 31 insertions(+)
 create mode 100644 CHANGELOG.md
 create mode 100644 VERSION

Berkas VERSION kini menyimpan versi berjalan agar skrip build bisa membacanya:

bash

cat VERSION

Output yang Dihasilkan:

text

1.2.0

Commit “Siapkan rilis v1.2.0” adalah titik pemotretan: semua yang mendefinisikan rilis — kode, changelog, versi — kini berada pada satu commit yang sama.

Langkah 5-6: Tag dan Push #

Tag annotated dibuat tepat pada commit persiapan itu:

bash

git tag -a v1.2.0 -m "Rilis v1.2.0: pencarian produk dan perbaikan tautan"

Perintahnya sunyi seperti biasa. Daftar tag memastikan ketiganya berbaris:

bash

git tag

Output yang Dihasilkan:

text
v1.0.0
v1.1.0
v1.2.0

Pengiriman ke pusat dilakukan dua kali: branch lebih dulu, lalu tag — mengingatkan perilaku git push yang tidak membawa tag sebagaimana dibuktikan di Berbagi Tag ke Remote :

bash

git push origin main

Output yang Dihasilkan:

text

To ../toko-pusat.git
   197ae11..e910f52  main -> main

bash

git push origin v1.2.0

Output yang Dihasilkan:

text

To ../toko-pusat.git
 * [new tag]         v1.2.0 -> v1.2.0

Langkah 7: Membangun Artefak dari Tag #

Artefak rilis — tarball, paket, berkas distribusi — dibangun dari tag, bukan dari posisi kerja terkini, agar isinya terkunci pada titik rilis. Git menyediakan git archive untuk mengemas isi commit menjadi berkas tar:

bash
git archive --format=tar --output=v1.2.0.tar v1.2.0

Perintah itu sunyi; hasilnya adalah berkas v1.2.0.tar yang isinya bisa diperiksa:

bash

tar -tf v1.2.0.tar

Output yang Dihasilkan:

text
CHANGELOG.md
VERSION
keranjang.md
produk.md
situs.md

Lima berkas — persis isi pohon kerja pada commit bertag v1.2.0, termasuk CHANGELOG.md dan VERSION yang barusan dibuat. Format zip tinggal mengganti --format=zip; teknik pengelolaan berkas rilis yang lebih jauh — menyertakan subtree atau prefiks direktori — dibahas di Mengelola File dan Repository .

Keadaan Akhir dan Langkah 8 #

Riwayat setelah seluruh alur berjalan terbaca utuh:

bash

git log --oneline --decorate

Output yang Dihasilkan:

text
e910f52 (HEAD -> main, tag: v1.2.0, origin/main) Siapkan rilis v1.2.0
d18d4e5 Perbaiki tautan rusak di beranda
f88f6b9 Tambah kolom pencarian produk
197ae11 (tag: v1.1.0) Tambah halaman produk
17183e2 Tambah keranjang belanja
f9d201b (tag: v1.0.0) Buat halaman beranda

Baris e910f52 (HEAD -> main, tag: v1.2.0, origin/main) menceritakan hasil alur: commit persiapan rilis menjadi HEAD, bertag v1.2.0 dan sudah tersinkron dengan origin/main. Hash akan berbeda di mesin pembaca; susunan dekorasinya yang penting. Langkah kedelapan — umumkan — di dunia nyata berupa GitHub Release yang menempelkan changelog dan artefak pada tag; mekanismenya dibahas di Release dan Tags di Platform Hosting .

Satu bahan rilis masih menyisakan pertanyaan: bagaimana persisnya baris “Added” dan “Fixed” di CHANGELOG.md disusun dari git log? Chapter berikutnya mengerjakannya langkah demi langkah: Changelog .