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