Dari pull request yang di-merge ke changelog yang terbit
Zero membaca pull request yang Anda merge minggu ini, menyisakan yang berdampak ke pengguna, menulis artikel changelog, lalu menerbitkannya ke blog, daftar Resend, dan X dalam satu proses yang sama begitu Anda menyetujui drafnya.
Yang Zero hasilkan: artikel, email, dan utas
Ini kabar produk Zero yang sungguhan, terbit di vm0.ai pada 20 Juli 2026 dan ditampilkan persis seperti saat dikirim: artikel blognya, kabar yang sama sebagai newsletter, dan sebagai utas di X. Satu proses menulis ketiganya dari pull request yang di-merge minggu itu.
Apa itu otomatisasi changelog?
Otomatisasi changelog adalah membuat kabar produk dari pekerjaan yang benar-benar di-merge tim Anda, bukan menulisnya dari ingatan di akhir minggu. Zero berperan sebagai agen di tengahnya: membaca pull request yang di-merge di GitHub, menyisakan yang berdampak ke pengguna, mengelompokkannya jadi tema, menulis artikel changelog, lalu menerbitkannya ke blog, newsletter Resend, dan utas X dalam satu proses. Hasilnya adalah kabar produk mingguan yang terbit tepat waktu dan berbunyi sama di semua kanal.
Kenapa changelog mingguan menghabiskan hari Jumat
Jumat sore. Ada tiga puluhan pull request yang di-merge minggu ini dan seseorang harus mengubahnya jadi kabar yang benar-benar dibaca orang. Anda menyisir daftar merge, menebak perubahan mana yang berdampak ke pengguna, menulis artikelnya, memangkasnya untuk email, memangkasnya lagi untuk X, lalu menempelkan tiap versi ke perkakas yang berbeda. Bacaan yang sama tiga kali, dan versi yang muncul di X biasanya berbeda sedikit dari versi yang masuk ke kotak masuk.
Bagaimana Zero mengubah satu minggu merge jadi changelog yang terbit
Langkah 1: Hubungkan alat Anda
Langkah 2: Tanya Zero
Langkah 3: Lanjutkan lebih jauh
Integrasi GitHub, Resend, X, dan Slack untuk otomatisasi changelog
Alur ini membaca dari satu perkakas dan menulis ke tiga. GitHub satu-satunya sumber kebenaran soal apa yang dirilis; Resend dan X adalah tujuan; Slack adalah tempat draf menunggu orang. Tiap konektor diberikan terpisah dan dibatasi pada apa yang benar-benar dipakai alur ini, jadi akses baca ke repositori Anda tidak pernah berarti hak memposting dari akun Anda.
Integrasi GitHub: yang Zero baca untuk menyusun changelog
WajibZero mengambil pull request yang di-merge ke repositori yang Anda sebutkan dalam rentang waktu Anda, dan untuk tiap pull request membaca judul, isi, label, waktu merge, penulis, serta jalur berkas yang berubah. Lima sinyal itulah yang memisahkan perubahan berdampak pengguna dari refaktor internal: label catatan rilis paling kuat, jalur berkas menangkap yang tak berlabel, dan isi melengkapi detail yang tak muat di judul. Pada alur ini integrasi GitHub bersifat baca saja. Zero tidak membuka issue, tidak melakukan commit, dan tidak mengubah pull request. Arahkan ke lebih dari satu repositori dan semuanya dibaca dalam satu jalan, sehingga frontend dan backend yang terpisah tetap menghasilkan satu changelog.
Integrasi Resend: newsletter yang Zero kirim
WajibZero membaca audiens Resend Anda agar bisa menyebut audiens itu dengan nama, bukan ID, lalu membuat dan mengirim kampanyenya: subjek, preheader, isi HTML, dan versi teks biasa. Setelah terkirim, Zero membaca hasilnya kembali dan melaporkan berapa pesan yang terkirim, tertunda, dan terpental. Itulah sebabnya laporan dan kampanye tak pernah berbeda angka. Izin kirim diberikan terpisah dari akses baca audiens, dan Zero tidak pernah menambah, menghapus, atau mengekspor kontak.
Integrasi X: utas yang Zero posting
WajibUtasnya ditulis untuk X, bukan potongan dari artikel blog: satu posting per tema, pembuka yang menyebut apa yang berubah, dan penutup yang menautkan ke tulisan lengkap. Zero memposting tiap entri sebagai balasan atas entri sebelumnya agar utasnya menyatu, dan mengecek panjangnya sebelum memposting, bukan membiarkan posting terpotong. Akses tulis dibatasi pada akun yang Anda hubungkan, dan memposting utas hanya itu yang dilakukannya. Zero tidak membaca linimasa, sebutan, maupun pesan langsung Anda.
Integrasi Slack: tempat draf menunggu persetujuan
OpsionalSlack bersifat opsional dan berguna pada tahap persetujuan. Zero memposting draf utuh di kanal yang Anda sebutkan, termasuk naskah blog, subjek email, dan tiap posting dalam utas, lalu berhenti. Tidak ada yang terbit sampai seseorang menyetujui, dan Anda bisa minta penulisan ulang di utas yang sama lalu menerima draf terbarunya di situ juga. Tanpa Slack, alurnya tetap berjalan penuh; draf kembali ke tempat Anda memulai prosesnya.
Zero dibanding menulis manual dan generator changelog
Otomatisasi changelog sebenarnya dua masalah: memutuskan apa yang layak diumumkan, dan membawa pengumuman itu ke semua kanal. Kebanyakan perkakas hanya menyelesaikan salah satunya.
Menulis manual
Seseorang membaca daftar merge, memutuskan mana yang penting, menulis artikelnya, lalu menulis ulang dua kali untuk email dan X. Pertimbangannya bagus dan naskahnya sesuai merek, tapi biayanya 90 menit yang sama tiap minggu dan inilah hal pertama yang dikorbankan saat minggu sedang padat.
Generator changelog
Judul commit atau pull request dikumpulkan otomatis jadi halaman catatan rilis. Tak ada merge yang terlewat, tapi yang terbit adalah judul, bukan tema; refaktor tak bisa dibedakan dari fitur; dan semuanya berhenti di satu tujuan.
Alur changelog Zero
Zero membaca merge yang sama, menerapkan aturan Anda soal apa yang berdampak ke pengguna, mengelompokkan sisanya jadi tema, dan menulis naskah untuk tiap kanal. Blog, Resend, dan X terbit dari satu draf yang disetujui dalam satu proses, dan prosesnya melaporkan apa yang ditahan beserta alasannya.
Tips untuk hasil yang lebih baik
Pertanyaan yang sering diajukan
Bagaimana cara mengotomatiskan changelog dari pull request GitHub?
Hubungkan GitHub ke Zero lalu beri jadwal atau pemicu rilis. Zero membaca pull request yang di-merge dalam rentang waktu Anda, menyaringnya dengan aturan Anda soal apa yang berdampak ke pengguna, mengelompokkan sisanya jadi tema, dan menulis artikel changelog. Tambahkan Resend dan X, maka proses yang sama juga menerbitkannya ke kanal-kanal itu.
Bagaimana Zero menentukan merge mana yang berdampak ke pengguna?
Dengan aturan yang Anda beri, diterapkan pada empat sinyal: label catatan rilis, jalur berkas yang berubah, judul pull request, dan isinya. Label adalah sinyal terkuat dan paling sering dibakukan tim. Semua yang dikecualikan Zero tercantum di laporan proses beserta alasannya, jadi keputusan yang keliru terlihat, bukan hilang diam-diam.
Bisakah satu draf terbit ke newsletter dan X sekaligus?
Bisa. Zero menulis temanya sekali, lalu menyesuaikannya per kanal: artikel utuh di blog, email sepanjang kotak masuk dengan subjek dan preheader, serta utas dengan satu posting per tema. Ketiganya terbit dalam proses yang sama dari draf yang sama, jadi faktanya tak mungkin melenceng antarkanal.
Apakah ada yang terbit tanpa persetujuan saya?
Tidak, kecuali Anda memintanya. Alur bawaan memposting draf ke sebuah kanal lalu menunggu. Anda bisa menyetujuinya, minta ditulis ulang di utas yang sama, atau membatalkannya. Kalau Anda memang ingin terbit tanpa pengawasan, sebutkan di prompt dan Zero melewati tahap persetujuan.
Perkakas apa saja yang dibutuhkan otomatisasi changelog ini?
GitHub wajib sebagai sumber apa yang dirilis. Resend dan X wajib sebagai dua tujuan penerbitan. Slack opsional dan hanya dipakai pada tahap persetujuan; tanpa Slack, draf kembali ke tempat Anda memulai prosesnya.
Izin apa yang dibutuhkan alur ini?
GitHub butuh akses baca ke repositori tempat Anda menerbitkan. Resend butuh izin kirim dan akses baca audiens. X butuh akses tulis pada akun yang memposting utas. Slack, bila dipakai, butuh izin memposting di kanal persetujuan. Tiap konektor diberikan terpisah di Zero, dan mencabut satu tidak memengaruhi yang lain.
Bisakah Zero menyusun satu changelog dari beberapa repositori?
Bisa. Sebutkan semua repositori di prompt dan Zero membacanya dalam satu jalan, lalu mengelompokkan perubahan berdasarkan perilaku yang berubah, bukan asal repositorinya. Frontend dan backend yang terpisah tetap menghasilkan satu artikel.
Bisakah dijalankan lewat tanda rilis alih-alih jadwal mingguan?
Bisa. Buat otomatisasi yang memulai alur ini saat sebuah rilis ditandai di GitHub. Zero lalu menyusun changelog dari pull request dalam rilis itu, bukan dari rentang tanggal, dan sisa prosesnya sama persis.
Terbitkan changelog minggu ini
Hubungkan GitHub, Resend, dan X, lalu pakai prompt mingguan untuk melihat seluruh prosesnya: periksa, kelompokkan, tulis draf, setujui, terbitkan.