Dari pull request yang di-merge ke changelog yang terbit
Okou 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.
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. Okou 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 Okou mengubah satu minggu merge jadi changelog yang terbit
Langkah 1: Hubungkan alat Anda
Langkah 2: Tanya Okou
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 Okou baca untuk menyusun changelog
WajibOkou 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. Okou 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 Okou kirim
WajibOkou 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, Okou 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 Okou tidak pernah menambah, menghapus, atau mengekspor kontak.
Integrasi X: utas yang Okou 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. Okou 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. Okou tidak membaca linimasa, sebutan, maupun pesan langsung Anda.
Integrasi Slack: tempat draf menunggu persetujuan
OpsionalSlack bersifat opsional dan berguna pada tahap persetujuan. Okou 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.
Okou 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 Okou
Okou 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 Okou lalu beri jadwal atau pemicu rilis. Okou 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 Okou 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 Okou 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. Okou 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 Okou 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 Okou, dan mencabut satu tidak memengaruhi yang lain.
Bisakah Okou menyusun satu changelog dari beberapa repositori?
Bisa. Sebutkan semua repositori di prompt dan Okou 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. Okou 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.