Apa itu Manajemen Rilis?
Manajemen rilis mencakup semua fase rilis perangkat lunak, mulai dari pengembangan dan pengujian hingga penerapan. Manajemen rilis diperlukan setiap kali produk baru diminta, atau bahkan perubahan pada produk yang sudah ada. Ada lima langkah pengelolaan rilis dasar yang kami ambil dalam situasi ini:
- Perencanaan rilis
- Rilis versi
- Pengujian penerimaan pengguna
- Persiapan rilis
- Terapkan rilis.
Perencanaan rilis
Fase perencanaan dalam banyak kasus intensif, karena pada tahap inilah seluruh rilis kami diatur dari awal hingga akhir. Rencana rilis yang andal membantu Anda tetap di jalur dan memastikan bahwa standar dan persyaratan ditaati dengan benar.
Saat merencanakan rilis, kami yakin bahwa aplikasi yang dikembangkan oleh banyak tim memerlukan pendekatan konsisten yang harus dirilis terlebih dahulu. Di sinilah konsep "pelepasan kereta" berperan. Dengan mengikuti pendekatan rilis kereta, tim dapat menjadwalkan perubahan berdasarkan rilis dan mengirimkannya ke Play Store.
Langkah paling pertama, bahkan sebelum kita mulai mengimplementasikan pelepasan kereta, adalah menentukan interval waktu untuk setiap tahapan. Dalam kasus kami, tahap pengembangannya adalah dua minggu. Selanjutnya, Anda perlu menentukan berapa banyak waktu yang ingin Anda habiskan untuk pengujian integrasi dan langkah-langkah penerapan. Di bawah ini adalah contoh jarak kita:
- Kliping: mulai hari 1.
- Pengujian internal versi alfa / UAT: Tiga hari.
- Penerapan bertahap [1%] Pengiriman untuk ditinjau.
- Durasi review: 3 hari.
- Suatu hari di 20% pengguna.
- Suatu hari dengan 50% pengguna, di hari yang sama, pertumbuhan menjadi 100% pengguna.
Berdasarkan contoh di atas, dibutuhkan total 10 hari hingga versi baru aplikasi tersedia secara umum.
Langkah selanjutnya menuju rilis adalah membuat alur kerja yang dapat dirujuk oleh tim kami dan pemangku kepentingan utama selama rilis.
Alur kerja segera menjelaskan bagaimana seluruh rilis bekerja dan peran apa yang dimainkan setiap anggota tim. Kami menggunakan alat Asana untuk menampilkan detail ini seperti yang tercantum di bawah ini:
- Pengaturan waktu
- Perkiraan Waktu Pengiriman
- Persyaratan
- Skala keseluruhan proyek
Setelah mengembangkan rencana, kami mengirimkannya ke semua pemangku kepentingan (grup rilis, manajer produk, dan pimpinan tingkat tinggi) untuk dipertimbangkan. Kami kemudian mendapatkan tanggapan mereka tentang setiap celah atau masalah yang mereka lihat dalam persyaratan atau aplikasi.
Setelah rencana disetujui dan diselesaikan, kesenangan dimulai!
Aspek penting dari perencanaan pelepasan
Membuat dan menggunakan rilis kereta terdengar bagus, tetapi menjaga proses tetap berjalan sambil merencanakan rilis kereta bisa jadi rumit. Berikut beberapa detail dari proses ini:
- Manajer rilis mengelola dan mengoordinasikan rilis.
- Kami hanya menerima kode yang telah ditinjau dan diuji.
- Ada tahapan implementasi dalam prosesnya.
- Kami sedang memantau versi rilis aplikasi.
Gedung rilis
Setelah rencana rilis siap, Anda dapat mulai menguji produk untuk dirilis. Ini akan menjadi "pengujian tingkat pengguna" yang sebenarnya dari produk berdasarkan persyaratan yang diuraikan dalam rencana rilis.
Pada hari dan waktu tertentu (katakanlah, Senin, pukul 15.00), kode dibekukan / dipotong. Hingga saat ini, tim memiliki waktu untuk melihat, menguji, dan menggabungkan fitur ke dalam cabang pengembangan, yang seharusnya menjadi bagian dari rilis kereta. Pada pukul 15:00, manajer rilis akan membuat cabang rilis dari cabang pengembangan. Langkah ini otomatis dengan Jenkins.
Dengan mengotomatiskan transisi cabang, kami memeriksa semua ambang batas kinerja, tolok ukur dan otomasi dari rilis sebelumnya ke pasar disetel ke yang saat ini sebagai dasar perbandingan, dan rilis kereta diblokir dari perubahan lebih lanjut.
Setelah kode dibekukan, siklus pengembangan baru dimulai, dan semua tim yang berpartisipasi memulai sprint baru dan melanjutkan pengembangan. Hal terbaik tentang rilis kereta api adalah bahwa semua orang tahu tentang rilis yang direncanakan berikutnya dan itu membantu orang-orang untuk merencanakan pekerjaan mereka dengan sesuai.
Rilis cabang dan kontrol versi
Pengembangan produk biasanya tidak berhenti ketika pengembangan untuk rilis selesai, jadi hal pertama yang kami pikirkan adalah cara membekukan versi yang sedang diuji dan pada saat yang sama mengerjakan fitur baru untuk rilis berikutnya. Apa yang terjadi jika kesalahan muncul dalam rilis build? Bagaimana cara memperbaiki kesalahan jika Anda telah menambahkan banyak hal baru sebelum kesalahan ditemukan?
Di sinilah strategi percabangan pintar masuk, yang memiliki konsep percabangan. Seperti namanya, kode bercabang berarti, seperti cabang pohon, kode cabang cocok dengan titik tertentu dan kemudian terbagi menjadi dua salinan.
Setiap cabang dapat berkembang secara independen satu sama lain. Dalam kasus ini, satu salinan - cabang rilis - tetap dibekukan di tempat Anda menyelesaikan pengembangan. Inilah yang kami sebut cabang terpotong. Cabang lain (cabang pengembangan) dapat diubah dengan kode baru dan perbaikan bug tanpa mempengaruhi cabang rilis sama sekali. Jika bug ditemukan di kandidat rilis, perbaikan dapat dikembangkan dan ditambahkan ke cabang rilis. Jadi, build berikutnya yang Anda buat dari cabang rilis mungkin sama dengan yang pertama, kecuali untuk satu perbaikan bug. Dengan cara ini, Anda dapat meminimalkan risiko bug baru dalam rilis dan mengisolasi bug dari kode baru. Perbaikan juga diterapkan ke cabang pengembangan untuk memastikan bahwa bug yang sama tidak berhasil masuk ke rilis berikutnya.Manfaat lain dari percabangan rilis adalah setelah Anda benar-benar memublikasikan kode, Anda memiliki cabang "beku", yang merupakan salinan persis dari basis kode yang dipublikasikan. Anda dapat kembali ke kode ini kapan saja untuk referensi.
Pengujian penerimaan pengguna
Pengujian penerimaan pengguna adalah langkah paling penting untuk manajemen rilis karena jumlah data yang dikumpulkan dan perbaikan yang diperlukan untuk membuat build persis seperti yang dibutuhkan untuk diluncurkan secara resmi.
Seperti namanya, ketika datang ke jenis pengujian ini, tokoh kuncinya adalah pengguna. Pengguna adalah orang-orang yang akan menggunakan aplikasi tersebut. Oleh karena itu, sangat penting untuk menjadikan pengguna sebagai bagian dari strategi penjaminan kualitas secara keseluruhan dalam proses pengembangan perangkat lunak. Di sinilah UAT berguna. Jenis pengujian ini menempatkan kebutuhan pengguna di pusat pengembangan produk tidak seperti yang lain. Berikut adalah beberapa pertanyaan yang coba dijawab oleh pengujian tersebut:
- Bisakah pengguna bekerja dengan aplikasi?
- Apakah aplikasi berperilaku seperti yang diharapkan?
- Apakah aplikasi menyelesaikan masalah pengguna?
Tanpa UAT (User Acceptance Testing) yang efektif, kemungkinan keberhasilan proyek yang sedang dikembangkan akan berkurang secara signifikan. Inilah mengapa kebiasaan menjadi bagian penting dari proses pengiriman. Seperti disebutkan sebelumnya, UAT adalah bagian dari proses berulang. Saat kesalahan teridentifikasi, tim akan kembali untuk memperbaikinya. Bug diperbaiki di cabang rilis dan kemudian digabungkan kembali ke cabang pengembangan. Build harus melalui tahap UAT sehingga dapat diperiksa untuk implementasi dan rilis akhir.
Tip Pro: Selalu Sertakan Pengujian Internal Dalam Perencanaan UAT!
Satu cara bagi kami untuk mempercepat rilis UAT adalah dengan menggunakan track pengujian internal yang disediakan oleh Google. Ini membantu kami mendistribusikan tiket dengan cepat ke kolega dan mendapatkan masukan mereka dengan membuat tiket JIRA secara otomatis. Tim juga memastikan bahwa umpan balik diperhitungkan sebelum mengirimkan tes akhir.
Persiapan dan rilis
Langkah ini untuk memberikan sentuhan akhir pada produk, dengan mempertimbangkan semua yang dipahami di UAT. Persiapan rilis juga mencakup pemeriksaan kualitas akhir oleh tim QC. Selama pemeriksaan, tim QA melakukan pemeriksaan akhir untuk memastikan bahwa perakitan memenuhi standar penerimaan minimum dan persyaratan bisnis dari rencana rilis.
Setelah peninjauan selesai, grup rilis akan menyelesaikan rilis untuk memulai penerapan. Sebelum perakitan dapat diterapkan di lingkungan hidup, itu harus disetujui oleh tim yang bertanggung jawab terkait seperti tim desain. UAT memastikan bahwa hasil divalidasi sebelum diteruskan ke tahap selanjutnya.
Menerapkan rilis
Akhirnya, hari besar tiba ketika semua kerja keras tim kami membuahkan hasil. Saatnya melepaskan produk kita ke alam liar untuk diproduksi. Selain hanya mengirimkan rakitan ke lingkungan produksi, tahap implementasi juga berisi pelatihan tentang cara bekerja dengan produk bagi pengguna akhir dan perusahaan secara keseluruhan. Misalnya, pengguna harus diberi tahu tentang perubahan dalam rilis, dan di sinilah "Apa yang Baru" tidak muncul di bidang tampilan. Kami memiliki proses Jenkins otomatis yang berisi langkah-langkah berikut:
- Pembuatan perakitan akhir [menentukan cabang dan nama versi].
- "What's New" ditambahkan dalam rilis.
- Menambahkan persentase penerapan.
- Setiap tahap memiliki input sinyal manual (merah / hijau) dari setiap perintah [UAT, benchmark, performance, automation].
Segera setelah sinyal mengizinkan build, build tersebut secara otomatis diupload ke Play Store dengan persentase penerapan yang ditentukan. Langkah-langkah internal untuk melakukan dan menandai versi, menyimpan rakitan ke Dropbox, menerbitkan dan memperbarui ke saluran Slack yang sesuai juga dilakukan melalui saluran yang sama.
Dalam hal ini, kami mulai dengan menerapkan hingga 1%. Pada setiap tahap, perlu untuk memantau review, serta alat untuk memantau penurunan rilis untuk mengidentifikasi kemungkinan masalah.
Jika kesalahan terlihat sebesar 1%, tim memiliki kesempatan untuk bereaksi terhadap masalah dan memutuskan apakah akan memperbaikinya dengan cepat. Jika demikian, maka pelepasan kereta seharusnya tidak mencapai tahap penerapan berikutnya sebesar 5%. Sebaliknya, masalah diselesaikan untuk 1% pengguna. Setelah masalah diperbaiki dan solusinya diverifikasi, pelepasan kereta dapat naik ke tahap 5%.
Seperti pada versi sederhana dari rilis kereta api, hanya teknisi rilis atau tim rilis yang menangani proses rilis setelah kode dibekukan. Semua tim lain melanjutkan perkembangan "normal".
Analisis pasca-rilis
Pekerjaan manajemen rilis tidak berakhir saat kode dipublikasikan, berlanjut hingga Anda siap untuk merilis rilis lagi. Jika Anda ingin aplikasi Anda berhasil, perlu tinjauan yang baik, Anda juga perlu mengikuti rilis dalam produksi untuk memperbaiki bug, menerapkan fitur yang dibutuhkan orang, dan menyelesaikan masalah pengguna. Untuk melakukan ini, kami menggunakan Firebase Crashlytics, tempat kami melacak setiap kerusakan yang memerlukan perbaikan segera.
Selain itu, ulasan aplikasi memberikan wawasan tentang produk Anda yang jauh lebih sulit didapat dengan pendekatan lain. Baik Google Play dan App Store memberi pengembang aplikasi kemampuan untuk menanggapi ulasan, yang bisa menjadi alat yang sangat berguna untuk mempelajari lebih lanjut tentang masalah aplikasi dari pengguna. Testimonial dapat mengidentifikasi masalah yang dialami pengguna dengan aplikasi Anda dan menginformasikan tentang perubahan di masa mendatang.
Mari kita simpulkan
Manajemen rilis mengawasi proses yang sangat dinamis. Setiap rilis adalah kesempatan untuk menyempurnakan semuanya, mulai dari alur kerja hingga daftar periksa kami, saat kami menemukan area untuk perbaikan dengannya. Berikut beberapa keuntungan yang kami dapatkan:
- Meningkatkan produktivitas kami dengan meningkatkan komunikasi dan koordinasi.
- Rilis kami dikirimkan lebih cepat, yang juga mengurangi risiko. Perubahan ini melibatkan tim yang dapat mengirimkan rilis berkualitas secara teratur dengan kecepatan tinggi.
- Manajemen rilis juga mendukung organisasi dan pengoptimalan metode pengembangan dan operasi.
Kami juga melihat bahwa proses manajemen rilis kami mempermudah semua orang - dari pengembang dan pemilik produk hingga eksekutif - untuk melihat rencana tingkat tinggi dan mendapatkan gambaran tentang kemajuan mereka, bekerja secara sinkron.
- Kursus DevOps
- Pelatihan profesi Ilmu Data
- Pelatihan Analis Data
- Python untuk Kursus Pengembangan Web