Melepaskan produk adalah bagian terpenting dari pekerjaan perusahaan perangkat lunak mana pun. Tetapi jika Anda takut untuk membuat rilis, maka mungkin Anda melakukan sesuatu yang salah. Saya akan memberi tahu Anda bagaimana saya biasanya mengatur rilis. Artikel ini tidak dimaksudkan untuk menjadi panduan lengkap karena semuanya individual dalam industri pengembangan perangkat lunak.
Bagaimana cara mempersiapkan rilis?
Pilih orang yang bertanggung jawab
Anda dapat bergantian bertugas, atau melempar dadu, atau menarik korek api - cara apa pun baik. Yang penting adalah rotasi orang dan pelatihan mereka yang tidak tahu cara membuat rilis. Misalnya, saat melempar dadu, Anda dapat memasukkan aturan bahwa orang yang bertugas terakhir kali memiliki hak untuk mentransfer, dan jika ia bertugas dua kali berturut-turut, maka secara otomatis Anda tidak sedang bertugas. Tugas tidak boleh dianggap sebagai hukuman atau wajib militer, dan harus ada orang yang dapat mengasuransikan.
Kustomisasi kalender
Tetapkan tanggal dalam kalender perusahaan dan pastikan semua pemangku kepentingan mengetahui.
Buat tabel di wiki
Tunjukkan versi tabel, tanggal dan orang yang bertanggung jawab untuk rilis. Ini lebih penting untuk menjaga data historis. Anda dapat dan harus segera mencatat apakah rilis berhasil dan apa sebenarnya yang termasuk dalam rilis.
Catatan rilis
Ini adalah "apa sebenarnya yang termasuk dalam rilis". Pertama-tama, data ini perlu dibagi dengan analis: mereka dapat membandingkan setiap perubahan dalam KPI dengan apa yang termasuk dalam rilis. Berdasarkan data ini, mereka dapat menarik kesimpulan tentang apa fungsi yang dibutuhkan pengguna, ide mana yang bagus dan mana yang tidak, dan apa yang akan masuk ke iterasi berikutnya.
Pengumuman internal
Penting bagi departemen lain untuk mengetahui kapan rilis itu terjadi, misalnya, untuk membuat posting di layanan sosial. jaringan tentang versi baru suatu produk (membuat panduan informasi), memantau KPI (metrik dapat naik atau turun), dll.
Selama rilis
Buat Rilis Brunch
Kode yang akan dirilis tidak boleh diubah, kecuali untuk memperbaiki bug kritis. Dan dalam kasus yang ideal, perbaikan apa pun harus melalui permintaan kumpulan. Juga, semua tes harus berwarna hijau.
Kirim Pemberitahuan
Anda perlu memberi tahu semua orang melalui surat atau di messenger bahwa brunch rilis telah dibuat dan persiapan sedang dilakukan untuk rilis.
Membuat tag
Pastikan untuk membuat tag saat rilis selesai, dan kencangkan perbaikan ke cabang pengembangan.
Buat rilis sendiri
Idealnya, Anda harus memiliki mekanisme yang mengontrol rilis: misalnya, lepaskan hanya 10% pengguna atau hanya non-pembayar. Ini perlu untuk itu. untuk mengurangi kerusakan dari kesalahan yang terjadi selama proses pengembangan dan tidak ditemukan selama pengujian.
Satu Tombol Rilis
Mitis Tentu saja, semakin sedikit faktor manusia yang terlibat dalam rilis, semakin baik. Tapi ini normal, kalau tidak semuanya bisa otomatis.
Jika semuanya berjalan sesuai rencana
Tentu saja, jika terjadi kesalahan, Anda tidak dapat saling menyalahkan, tetapi Anda harus menyelesaikan masalah bersama dan membuat rencana untuk mencegah insiden seperti itu di masa mendatang.
Setelah rilis
Untuk memantau
Jangan lupa memonitor kesalahan, load server. Penting juga memperhatikan KPI: jika Anda membuat rilis dan DAU Anda jatuh, maka mungkin ada sesuatu yang tidak berfungsi sebagaimana mestinya, atau alat pemantauan sendiri rusak. Setiap aktivitas mencurigakan perlu diperiksa.
Laporkan keberhasilan dan kegagalan
Jauh lebih baik jika mereka mengetahui masalah dari pengembang, bukan dari pengguna. Dan tentu saja, jika Anda telah memecahkan masalah apa pun, maka Anda dapat membualnya dengan aman.
Retrospektif
Ini, tentu saja, sebagian tergantung pada metodologi pengembangan, tetapi jika ada yang salah selama proses rilis, ada baiknya dibahas. Jika ada sesuatu yang baik, maka itu juga layak dibahas. Idealnya, di papan tulis untuk setiap titik kegagalan harus menjadi titik keberhasilan atau terima kasih kepada kolega. Ini akan membantu untuk tidak menggulung retrospektif menjadi mengomel dan negatif.
Pesan pizza dan rayakan
Selama pertemuan seperti itu, hanya kolega yang menjadi teman dan kawan. Dan ini berarti bahwa dalam pertempuran berikutnya, teman tidak akan mengecewakan Anda.
Mulai bersiap untuk rilis berikutnya
Saya sangat suka gagasan kereta Rilis, ketika setiap rilis berlangsung secara teratur pada tanggal yang jelas. Berkat ini, mekanisme rilis didebug oleh tim. Seperti yang saya tulis di atas, tidak perlu untuk melepaskan ke 100% pengguna: itu dapat diluncurkan ke sekelompok kecil orang.
Bagaimana rilis perusahaan lain?
Spotify
Spotify akan sering rilis berdasarkan praktik kereta rilis. Seperti yang ditunjukkan oleh nama latihan ini, rilis ini sangat mirip dengan kereta api: mereka yang belum punya waktu untuk menyelesaikan pekerjaan mereka sedang menunggu rilis berikutnya. Keuntungan dari pendekatan ini adalah bahwa tim yang gagal tidak menunda pengiriman produk dan tidak mencoba untuk mendorong tugas yang belum selesai. Dan akibatnya, devops tidak memiliki ponsel mereka sobek di malam hari, dan tim tugas tidak muncul bekerja dengan tas di bawah mata di pagi hari. Tentu saja, pendekatan ini tidak akan bekerja untuk perusahaan outsourcing: klien tidak akan membayar untuk pekerjaan yang belum selesai. Terus terang: Saya suka budaya perusahaan, saya menyarankan Anda untuk menonton video (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) tentang cara kerjanya.
Pemesanan
Orang-orang ini juga sangat keren. Rilis mereka didasarkan pada tes A / B. Misalkan ada versi stabil saat ini - versi A, dan ada versi yang baru saja selesai dibuat pengembang - versi B. Jika KPI lebih baik di versi B, maka ada baiknya meningkatkan persentase pengguna untuk versi ini. Jika versi B lebih buruk, maka ada dua opsi: versi B sama sekali tidak stabil atau hanya fitur yang tidak diperlukan siapa pun. Pendekatan ini cocok untuk perusahaan yang menangani produk kerjanya, tetapi kemungkinan besar tidak akan membuat revolusi. Jika Anda tertarik mempelajari lebih lanjut tentang lean manufacturing, bacalah buku Lean Startup (http://theleanstartup.com/).