Blog changeloop
Catatan rilis, dalam praktik
Dua hal yang sering kami pikirkan: cara menulis catatan rilis yang dibaca orang, dan cara berhenti mengelola changelog secara manual. Tanpa newsletter, tanpa pendaftaran. Hanya tulisan.
Release notes perbaikan bug: cara menulis entri yang berguna
Release notes perbaikan bug berhasil bila tiap entri menyebut gejala, siapa yang terkena, dan langkah berikutnya. Ada contoh sebelum dan sesudah.
Praktik catatan rilis6 menit baca
Cara meminta umpan balik pelanggan di produk software
Ajukan satu pertanyaan spesifik tepat setelah pengguna melakukan sesuatu, di tempat mereka bekerja. Kalimat siap pakai per momen dan contoh yang buruk.
Siklus umpan balik7 menit baca
Contoh roadmap produk: enam format dan cara gagalnya
Enam contoh roadmap produk dengan item realistis: Now/Next/Later, kuartalan, tema, hasil, publik, dan rilis. Cocok untuk siapa dan bagaimana gagalnya.
Siklus umpan balik6 menit baca
Proses manajemen rilis untuk tim yang sering merilis
Proses manajemen rilis untuk tim software dalam tujuh langkah, dengan pemilik dan kriteria selesai tiap langkah, plus metrik DORA dan satu KPI tambahan.
Engineering6 menit baca
Contoh release notes untuk setiap jenis perubahan
Contoh release notes untuk fitur, perbaikan, breaking change, perbaikan keamanan, deprecation, catatan app store, dan catatan internal, beserta alasannya.
Praktik catatan rilis7 menit baca
Versioning API Stripe: cara kerjanya dan apa yang ditiru
Versioning API Stripe mengunci tiap akun ke versi bertanggal dan membolehkan setiap request menimpanya. Cara kerja, biaya, dan yang bisa ditiru API kecil.
Perubahan API6 menit baca
Siapa yang menulis changelog, dan siapa yang seharusnya
Siapa yang menulis changelog? Penulis PR tahu apa yang berubah, PM tahu kenapa itu penting. Sendirian, keduanya tidak menulis entri yang berguna.
Engineering5 menit baca
Release notes darurat: menulis di bawah tekanan waktu nyata
Rilis yang dipicu insiden butuh catatan yang ditulis dalam hitungan menit, bukan hari. Proses penulisan biasa mengasumsikan waktu yang tidak Anda miliki.
Praktik catatan rilis5 menit baca
Protobuf breaking changes: apa yang bertahan di wire
Protobuf breaking changes terjadi di wire, bukan di URL. Sebagian perubahan field gRPC gratis, sebagian merusak setiap client diam-diam, dan tampak sama.
Perubahan API5 menit baca
Format berkas changelog: JSON, YAML, atau cukup Markdown
Format berkas changelog menentukan apakah ia bisa memasok halaman dan widget, atau hanya dibaca manusia. Markdown, JSON, dan YAML punya biaya yang berbeda.
Engineering5 menit baca
Permintaan fitur duplikat: menggabung tanpa kehilangan suara
Mengelompokkan permintaan duplikat melindungi hitungan. Menggabung sembarangan menghilangkan kata-kata pembuat satunya berguna, kerugian yang lebih kecil.
Siklus umpan balik5 menit baca
Deprecation GraphQL tanpa nomor versi
GraphQL tidak punya v1 atau v2 di URL. Field di-deprecate satu per satu dengan directive, pada satu skema bersama, yang mengubah kewajiban changelog.
Perubahan API5 menit baca
Cara menulis panduan migrasi API
Panduan migrasi API mengubah perubahan tak kompatibel menjadi checklist, bukan gangguan. Apa yang dibutuhkan, dan mengapa entri changelog saja tak cukup.
Perubahan API4 menit baca
Check changelog untuk GitHub Actions
Check changelog di GitHub Actions menolak merge tanpa entri, karena langkah yang bergantung pada ingatan akan gagal. Plus apa yang dirusak oleh check itu.
Engineering5 menit baca
Cara menolak permintaan fitur tanpa kehilangan pelanggan
Menolak permintaan fitur adalah separuh sulit dari menutup lingkaran. Cara bilang tidak tanpa merusak hubungan dengan pelanggan, setelah yang mudah.
Siklus umpan balik4 menit baca
Release notes feature flag: apa yang disampaikan, dan kapan
Release notes feature flag harus membedakan merge dan rilis, yang tak lagi sama saat ada flag. Menutup lingkaran terlalu dini mengumumkan fitur gaib.
Siklus umpan balik5 menit baca
Cara melacak permintaan fitur tanpa kehilangannya
Pelacakan permintaan fitur biasanya gagal dua cara: tidak sampai ke mana pun, atau sampai tempat yang tak pernah dilihat lagi. Sistem yang tahan keduanya.
Siklus umpan balik5 menit baca
Ketika permintaan fitur sebenarnya adalah laporan bug
Tiket dukungan yang meminta pengaturan baru bisa jadi cara mengakali bug tersembunyi. Label yang salah mengirimnya ke pemilik dan antrean yang salah.
Siklus umpan balik4 menit baca
Tiket dukungan vs. permintaan fitur: mana yang Anda percaya?
Tiket dukungan dan papan permintaan fitur mengukur hal berbeda, dan memperlakukan lonjakan di satu setara yang lain menghasilkan prioritas yang salah.
Siklus umpan balik5 menit baca
Tag git, rilis, dan changelog Anda
Tag git, rilis, dan entri changelog adalah tiga catatan dari satu peristiwa. Mencampuradukkannya membuat changelog melenceng. Cara ketiganya selaras.
Engineering4 menit baca
Release notes internal: siapa lagi yang perlu tahu
Tim support dan sales biasanya tahu soal peluncuran dari pelanggan yang bingung. Release notes internal memperbaikinya, dengan bentuk yang berbeda.
Praktik catatan rilis5 menit baca
Changelog API internal: apa yang berubah bagi tim lain
Changelog API publik punya audiens yang tidak bisa dihubungi langsung. Yang internal punya audiens dua lantai jauhnya, dan itu mengubah isinya.
Perubahan API5 menit baca
Release notes mobile: apa yang dipotong batasan
App Store dan Play Store memberi beberapa baris terlihat dan tanpa tautan. Yang berhasil di changelog web akan gagal dengan anggaran sesempit itu.
Praktik catatan rilis4 menit baca
Changelog monorepo: satu saja, atau satu per paket?
Monorepo bisa punya satu changelog untuk seluruh repo atau satu per paket. Salah pilih membuat rilis terlalu berisik dibaca atau terlalu tersebar dicari.
Engineering5 menit baca
Cara mengumumkan fitur baru (tanpa keheningan)
Kebanyakan pengumuman fitur mati di kanal yang tak dibaca dua kali. Di mana mengumumkan, apa yang dikatakan lebih dulu, dan siapa yang harus dijangkau.
Praktik catatan rilis5 menit baca
Memprioritaskan permintaan fitur yang menumpuk
Backlog yang terlacak masih menyisakan pertanyaan sulit: permintaan mana yang jalan dulu. Kerangka yang berguna, dan di mana masing-masing gagal.
Siklus umpan balik5 menit baca
Release notes enterprise: apa yang berubah untuk satu akun
Release notes enterprise untuk pelanggan di build privat harus sesuai instansnya. Salah menyesuaikan bisa membocorkan roadmap atau membingungkan support.
Praktik catatan rilis5 menit baca
Semantic versioning dan changelog Anda
Semantic versioning memberi tahu seberapa sakit sebuah rilis sebelum changelog dibaca. Apa yang dijanjikan tiap angka, dan tanggung jawab sebuah entri.
Engineering5 menit baca
Changelog webhook: breaking change yang tak diminta
Perubahan payload webhook rusak diam-diam, karena tak ada pemanggil yang bisa menolaknya. Apa yang membuat payload breaking, serta cara memberi versi.
Perubahan API5 menit baca
Header sunset API, dan kapan mengirimkannya
Header sunset API memberi tahu klien kapan versi berhenti merespons, beda dari notifikasi deprecation. Cakupan RFC 8594, dan manfaat brownout sebelumnya.
Perubahan API5 menit baca
Apa itu changelog? Pengertian dan contohnya
Changelog adalah catatan bertanggal tentang apa yang berubah pada sebuah produk. Contoh entri, bedanya dengan release notes, dan di mana sebaiknya ditaruh.
Praktik catatan rilis4 menit baca
Changelog API: apa yang dipublikasikan, siapa pembacanya
Changelog API dibaca orang yang memutuskan apakah kodenya masih berfungsi bulan depan. Apa yang harus diberikan tiap entri, letaknya, dan cara langganan.
Perubahan API6 menit baca
Cara membangun halaman changelog yang diikuti orang
Halaman changelog layak dibangun ketika orang kembali lagi. Di mana letaknya, apa yang dibutuhkan tiap entri, feed dan markup, serta posisi widget.
Engineering5 menit baca
Template email update produk yang dibaca orang
Email update produk yang dibaca dikirim ke orang yang memintanya. Sebuah template, empat jenis email, subjek yang efektif, segmentasi, dan persetujuan.
Praktik catatan rilis5 menit baca
Cara men-deprecate API tanpa kehilangan developer
Deprecation adalah janji dengan tanggal. Jadwalnya, template pemberitahuan, header respons, dan langkah yang mencegah sunset menjadi insiden.
Perubahan API6 menit baca
Praktik terbaik versi API, demi kepentingan pemanggil
Versikan hanya yang merusak, taruh versinya di tempat yang terlihat pemanggil, dan jaga versi lama berjalan sampai tanggal tertentu. Empat skema.
Perubahan API6 menit baca
Breaking change: apa yang terhitung dan cara merilisnya
Breaking change adalah perubahan yang tidak bisa dilalui pemanggil yang benar. Apa yang terhitung, apa yang tidak, cara menangkapnya di CI, dan merilisnya.
Perubahan API8 menit baca
Menutup lingkaran umpan balik dari sisi changelog
Lingkaran umpan balik tertutup saat peminta tahu fiturnya sudah dirilis. Empat langkahnya, di mana ia putus, dan mengapa changelog tempat yang tepat.
Siklus umpan balik7 menit baca
Template permintaan fitur yang menjadi changelog
Permintaan fitur hanya berguna jika bisa ditemukan lagi saat dirilis. Template, label yang mengarahkannya, dan kolom yang kemudian dibaca changelog.
Siklus umpan balik5 menit baca
Roadmap publik dari issue tracker Anda, tiga kolom
Roadmap publik adalah janji tentang masa depan. Buat tetap kecil, isi dari issue yang sudah dilacak, dan pindahkan setiap item lewat label di issue-nya.
Siklus umpan balik5 menit baca
Otomatisasi changelog, dan batasannya
Otomatisasi pengumpulan, pemformatan dan penerbitan. Jangan otomatisasi seleksi atau formulasi. Di mana batasnya dan apa yang terjadi setiap kali bergeser.
Engineering5 menit baca
Changelog vs release notes: apa bedanya?
Changelog adalah catatan berkelanjutan untuk yang mencari sesuatu. Release notes adalah pesan terkurasi untuk yang memutuskan apakah itu penting.
Praktik catatan rilis5 menit baca
Dari conventional commits ke changelog
Conventional commits membuat changelog bisa diturunkan, tetapi tidak mudah dibaca. Apa yang diberikan konvensi, di mana berhenti, dan cara menutup celah.
Engineering5 menit baca
Cara menulis release notes yang benar-benar dibaca orang
«Perbaikan bug dan peningkatan performa» bukan release note. Pertanyaan yang harus dijawab setiap entri, dan penulisan ulang dari satu yang nyata.
Praktik catatan rilis5 menit baca
Keep a Changelog, benar-benar diimplementasikan
Spesifikasi Keep a Changelog hanya satu halaman. Saat implementasi, tim menyimpang. Apa katanya, apa yang dibiarkan terbuka, dan di mana salahnya.
Engineering4 menit baca
Praktik terbaik release notes yang layak dipertahankan
Kebanyakan daftar praktik terbaik adalah saran gaya. Ini mengubah apa yang dilakukan pembaca, dan tiga saran populer yang ternyata kultus kargo.
Praktik catatan rilis5 menit baca