Pause akan menghentikan rollout dari mencapai lebih banyak perangkat. Rollback akan mengarahkan perangkat yang terkena ke versi yang diketahui baik. Capgo supports both, so you can contain a problem first and decide what to do next.
Gunakan langkah-langkah ini untuk memilih aksi yang tepat, memeriksa efeknya, dan mengurangi kemungkinan kejadian itu terulang.
Kami membaca 6 panduan publik tentang rollouts yang dipersiapkan dan rollback yang diterbitkan oleh Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform, dan Digia. Empat dari 6 memisahkan pause dari rollback sebagai aksi yang berbeda, sedangkan 2 melupakan rollback atau menganggap pause sebagai satu-satunya pengaturan. Tidak ada dari 6 yang menjelaskan cara memastikan pemulihan dengan analisis atau periksa perangkat, dan tidak ada yang menjelaskan alur kerja untuk mencegah insiden yang berulang. Mendapatkan pilihan pause-versus-rollback yang tepat, kemudian memastikan bahwa itu berhasil, menutup celah yang ditinggalkan di seluruh panduan rilis publik.
Isi Kandungan
- Langkah 1: Atur pengendalian rilis di Capgo
- Langkah 2: Pilih apakah ingin mematikan atau mengembalikan
- Langkah 3: Hentikan penyebaran lebih lanjut sementara Anda menyelidiki
- Langkah 4: Kembalikan ke versi stabil ketika pengguna membutuhkannya
- Langkah 5: Verifikasi pemulihan dengan analisis dan periksa perangkat
- Langkah 6: Mencegah insiden yang sama dengan alur rilis yang lebih aman
- FAQ
- Kesimpulan
Langkah 1: Atur pengendalian rilis di Capgo
Before an incident, make sure your team knows which channel is delivering the release and which bundle is stable. A channel is a named lane that directs app devices to an update. A bundle is the updateable web code sent through that lane.
Dalam Capgo, peluncuran progresif dapat mempertahankan bundle stabil sementara mengirimkan target peluncuran terpisah ke kelompok yang dipilih. Ini memberikan titik kontrol sebelum bundle baru mencapai basis pengguna yang lebih luas. Periksa pengendalian peluncuran progresif sebelum mengaktifkannya di produksi. Pengendalian Peluncuran Progresif
Catat pemilik rilis dan signal yang harus menghentikan ekspansi. Misalnya, putuskan apa yang tim Anda akan lakukan jika gagal update meningkat, layar utama berhenti berfungsi, atau laporan dukungan bahwa pengguna tidak bisa menyelesaikan tugas. Tetapkan batasan berdasarkan perilaku aplikasi normal Anda, bukan memilih ambang batas hanya karena terdengar ketat.
Update OTA mengubah aplikasi code yang dapat diperbarui secara daring. Ini tidak menggantikan aplikasi native yang diinstal dari toko aplikasi. Istilah update OTA menggambarkan pendekatan pengiriman ini. Ingat batasan ini: jika perbaikan memerlukan plugin native baru atau perubahan pengaturan aplikasi native, rollback bundle tidak akan menyediakannya.
Sebelum rilis, pastikan bundle stabil yang Anda harapkan. Periksa nama saluran, bundle target, dan status peluncuran. Kesalahan tipe nama saluran atau target yang ketinggalan zaman dapat mengarahkan respons ke kontrol yang salah ketika menit berharga.
Seharusnya Anda sudah memiliki pemilik rilis yang dinamai, bundle yang baik, dan kondisi berhenti yang ditulis. Persiapan itu mengubah keputusan berikutnya menjadi pilihan operasional, bukan kekacauan melalui dashboard.
Key Takeaway: Paus membatasi eksposi baru. Rollback mengubah versi yang diarahkan pengguna untuk menerima.
Langkah 2: Pilih untuk menunda atau kembali ke versi sebelumnya
Untuk keputusan pause rollout vs rollback Capgo, tanyakan pertanyaan pertama: apakah Anda mencoba menghentikan lebih banyak perangkat untuk mendapatkan target, atau menggerakkan perangkat dari target yang sudah menyebabkan kerusakan? Pause membatasi paparan baru. Rollback membersihkan target dan kembali perangkat ke fallback stabil pada periksa update berikutnya.
Pilih pause ketika bukti belum lengkap atau masalah tampak terbatas. Anda mungkin memiliki beberapa laporan tetapi tidak tahu apakah bug mempengaruhi jenis perangkat tertentu, alur pengguna tertentu, atau setiap perangkat yang diperbarui. Menghentikan memberikan tim ruang untuk memeriksa signal tanpa menambahkan perangkat baru ke grup rollout.
Pilih rollback ketika target jelas tidak aman untuk pengguna, atau ketika tim memiliki bukti yang cukup bahwa bundle yang diketahui baik lebih aman. Pause sendiri tidak menghapus target buruk dari perangkat yang sudah dalam kelompok rollout. Jika pengguna tersebut perlu kembali ke stabil, rollback adalah aksi yang mengubah jalur update mereka.
The Capgo saluran CLI referensi Kontrol pause dan rollback terpisah. Tanganilah mereka sebagai aksi yang berbeda, bukan dua nama untuk satu penghentian darurat.
| Apakah yang Anda lihat | Aksi pertama | Apa yang perlu diperiksa selanjutnya |
|---|---|---|
| Kesalahan awal, ruang lingkup tidak jelas | Apakah yang perlu Anda periksa selanjutnya | Kesalahan awal, ruang lingkup tidak jelas |
| Bug yang diketahui mempengaruhi kelompok target | Rollback target | Konfirmasi bahwa paket stabil aktif |
| Masalah terkait dengan native code atau layanan | Pause atau mengisolasi perubahan aplikasi, lalu perbaiki layer yang terkena dampak | Periksa apakah perbaikan native atau layanan diperlukan |
| Hanya sekelompok kecil yang memiliki target, dengan tidak ada dampak pengguna yang dikonfirmasi | Pause sementara menyelidiki | Resume hanya setelah pemilik rilis menyetujui |
Rollback tidak akan memperbaiki gangguan backend, dan tidak dapat menambahkan kemampuan native yang hilang. Pertama-tama identifikasi layer mana yang gagal. Jika paket web yang bersalah, pilih antara pause dan kembali berdasarkan berapa banyak pengguna yang membutuhkan keringanan.
Langkah 3: Pause ekspose lebih lanjut sementara Anda menyelidiki
Jalankan pause ketika Anda perlu menghentikan perangkat baru dari masuk ke dalam kelompok peluncuran tetapi belum siap untuk mengembalikan target untuk perangkat yang sudah ada di dalamnya. Ini adalah langkah pengamanan. Ini membeli waktu untuk memeriksa fakta sementara menghindari masalah menyebar ke pengguna lain.
Terbuka saluran produksi dan pastikan Anda beraksi pada peluncuran yang terkena dampak. Jalankan pause dengan dashboard, CLI, atau API yang digunakan tim Anda. Kemudian baca kembali keadaan saluran. Jangan hanya bergantung pada perintah yang berhasil; pastikan peluncuran sekarang menampilkan sebagai pause.
Dalam model peluncuran progresif Capgo, perangkat yang sudah ada di dalam kelompok dapat tetap pada target peluncuran setelah pause. Perangkat baru yang layak menerima fallback stabil pada cek berikutnya. Perbedaan ini penting: pause menghentikan masuk baru, tetapi itu sendiri tidak menggerakkan kelompok yang ada kembali ke stabil.
Selanjutnya, catat detail rilis sebelum membuat perubahan lain. Rekam bundle target, saluran, waktu pause, dan laporan pertama yang diketahui. Simpan detail perangkat atau sesi yang tim Anda diperbolehkan untuk mengumpulkan. Garis waktu yang jelas membantu Anda membandingkan kelompok peluncuran dengan perangkat yang masih menggunakan bundle stabil.
Cek masalah melalui jalur yang dapat diulang. Jika pengguna melaporkan gagal login, tes perjalanan yang sama pada perangkat yang terkena dampak. Jika aplikasi mengalami crash pada saat peluncuran, periksa apakah crash tersebut sesuai dengan bundle baru dan versi aplikasi native. Hindari menganggap setiap laporan dukungan sebagai bukti bahwa pembaruan menyebabkan masalah.
Setlah pemilik dan waktu keputusan untuk penyelidikan. Rollout yang terhenti dapat berada dalam keadaan kacau jika tidak ada yang mengambil langkah selanjutnya. Pemilik harus memutuskan untuk melanjutkan setelah bukti telah membersihkan rilis atau memilih rollback ketika target tetap tidak aman.
Trik Pro: Hubungi dukungan dan tim rilis bahwa rollout telah dihentikan. Jika tidak, satu kelompok mungkin terus mengangkat laporan sementara kelompok lain menganggap rollout telah dibalik.
Seharusnya perangkat baru tidak lagi memasuki kelompok rollout. Periksa status saluran dan perilaku perangkat yang tidak pernah masuk kelompok sebelum melanjutkan ke rollback atau melanjutkan.
Langkah 4: Roll back ketika pengguna membutuhkan versi stabil
Roll back when users already on the target need to move back toward a known-good bundle. This is the stronger response than pausing. It changes what the channel serves, so verify the selected stable build before you confirm the action.
In Capgo, open the affected channel and review its build history. Choose the version you want to restore, then confirm that it is the correct stable bundle for this app and channel. Capgo’s Dokumentasi Rollback Menggambarkan jalur dashboard dan mencatat bahwa perangkat akan menerima build yang dipilih pada saat mereka memeriksa pembaruan berikutnya.
After rollback, don’t assume every device changed at once. A device needs to check for an update, and an offline user may not do that until later. Keep the incident open until you’ve checked the channel’s active version and tested the recovery path on a device in the affected cohort.
Gunakan bundle bawaan hanya ketika itu adalah target pemulihan yang dimaksudkan. Ini mengarahkan perangkat kembali ke build web yang dikemas di dalam aplikasi native, yang mungkin berbeda dari bundle OTA terakhir. Periksa konsistensi dan dampak pengguna sebelum memilihnya sebagai langkah pemulihan Anda.
Simpan bundle yang menyebabkan insiden tersedia untuk analisis kecuali proses penyimpanan Anda mengatakan sebaliknya. ID rilis dan komit membantu insinyur membandingkan perubahan dengan versi stabil. Simpan log yang relevan sebelum membersihkan, terutama jika Anda perlu memahami mengapa masalah melarikan diri dari pengujian.
Rollback bukanlah solusi yang tepat untuk setiap kegagalan. Jika penyebab utama adalah dependensi server, perbaiki layanan tersebut. Jika perubahan bergantung pada native code yang tidak ada di dalam biner yang terpasang, siapkan build native dan ikuti jalur rilis aplikasi toko untuk perubahan tersebut.
Langkah 5: Verifikasi pemulihan dengan analitis dan periksa perangkat
After a pause or rollback, verify what devices are doing rather than treating the control change as proof of recovery. Check the active channel state first. Then compare update adoption, errors, and device reports across the affected release and the stable version.
Capgo’s live update analytics dapat membantu Anda memeriksa metrik adopsi, tingkat kesalahan, dan log perangkat. Gunakan sinyal-sinyal tersebut untuk menjawab pertanyaan spesifik: apakah perangkat baru masih menerima target yang ditargetkan, apakah perangkat yang terkena cek untuk bundle stabil, dan apakah kegagalan yang dilaporkan berhenti setelah pemulihan?
Uji jalur pengguna yang gagal. Download yang sukses tidak membuktikan bahwa aplikasi berfungsi. Buka layar relevan, ulangi aksi yang menyebabkan laporan, dan verifikasi bahwa aplikasi mencapai keadaan yang diharapkan. Jika insiden melibatkan alur kritis, minta orang lain selain orang yang melakukan perubahan untuk memastikan hasilnya.
Bandingkan yang serupa dengan yang serupa. Jumlah kesalahan yang luas mungkin meningkat karena alasan yang tidak terkait dengan rilis, seperti masalah layanan atau perubahan lalu lintas. Filter berdasarkan bundle, saluran, versi aplikasi, dan perangkat jika tersedia. Cari perbedaan yang terkait dengan rilis daripada menyalahkan pembaruan terbaru secara default.
Periksa juga pengguna yang belum diperbarui. Hadirnya mereka dapat membuat metrik keseluruhan terlihat sehat sementara kelompok yang terkena masih melihat bug. Ikuti bagian perangkat yang menjalankan target terhadap bagian yang menjalankan stabil, dan tahan laporan dukungan terhadap versi yang digunakan pengguna.
Catat hasil pemulihan dan ketidakpastian yang masih ada. Jika kesalahan menurun tetapi beberapa pengguna masih melaporkan masalah yang sama, jangan tutup insiden sampai Anda memahami apakah mereka offline, menggunakan shell native yang lebih tua, atau masih menggunakan bundle yang terkena.
Ketika saluran menunjuk ke versi yang diinginkan dan jalur pengguna yang gagal berfungsi pada perangkat yang dapat mengulangi masalah, maka pemulihan telah dikonfirmasi. Data membantu Anda melihat bentuk masalah; perangkat cek mengonfirmasi apa yang dialami oleh orang tersebut.
Langkah 6: Mencegah insiden yang sama dengan alur rilis yang lebih aman
Pastikan pause dan rollback menjadi bagian dari rencana rilis sebelum mempublikasikannya. Pemilik rilis harus mengetahui siapa yang dapat menghentikan paparan dan siapa yang dapat menyetujui kembali ke stabil. Hal ini menghilangkan hambatan umum: menunggu pertemuan sementara lebih banyak perangkat memasuki proses rollout.
Tetapkan fallback stabil yang ditugaskan selama target rollout diuji. Gunakan kelompok kecil yang ditentukan terlebih dahulu, kemudian luaskan hanya ketika signal kesehatan yang disepakati tetap dalam batas Anda. Capgo mendukung pengendalian rilis berdasarkan saluran, sehingga tim dapat memisahkan pengujian dari pengiriman produksi yang luas.
Masukkan periksa rilis ke CI/CD, proses otomatis yang menjalankan tes dan mengirimkan perubahan. Pipa dapat mempublikasikan bundle ke saluran yang diinginkan setelah tes berhasil. Pipa juga harus gagal dengan aman jika saluran salah atau rilis tidak siap untuk promosi.
Alur rilis yang terus-menerus menjaga perangkat siap untuk rilis melalui proses otomatis. Untuk alur OTA, pastikan titik persetujuan manusia tetap jelas meskipun publikasi otomatis. Otomatisasi harus membuat aksi yang dipilih dapat diulang, bukan membuat keputusan untuk perubahan yang belum direview.
Untuk Capgo, proses pengiriman satu perintah dapat menerbitkan bundle ke saluran. Simpan perintah tersebut di proses rilis yang sama dengan cek Anda, dan buat saluran target terlihat di catatan pengiriman. Hal ini membantu insinyur yang bertugas melihat secara tepat apa yang dikirimkan tanpa harus menebak jalur mana yang menerima pengiriman tersebut.
Sebelum mengaktifkan perlindungan otomatis, tentukan apa yang menyebabkan mereka diaktifkan dan apa yang mereka lakukan. Pause dapat menghentikan paparan baru sementara menjaga perangkat kohort saat ini tetap pada target. Rollback dapat mengarahkan perangkat ke versi stabil. Kedua hasilnya berbeda, jadi jangan mengkonfigurasi salah satu sebagai yang lain.
Pilih saluran uji untuk merehearsikan respons penuh. Publikasikan perubahan yang tidak berbahaya, verifikasi kontrol pause, dan kemudian uji rollback ke bundle sebelumnya. Pastikan perilaku aplikasi pada perangkat setelah setiap aksi. Buku catatan tertulis harus mencakup saluran, perintah atau jalur dashboard, keadaan yang diharapkan, dan orang yang mengkonfirmasi kesuksesan.
Catatan rilis harus mengidentifikasi bundle dan tujuan. Simpan link antara catatan pengiriman dan perubahan sumber sehingga insinyur dapat mempersempit pencarian ketika terjadi kesalahan. Jika tim Anda mentransfer kasus ke zona waktu yang berbeda, termasuk aksi terakhir yang diambil dan pemilik keputusan berikutnya.
Jika kasus tersebut menunjukkan bottleneck implementasi front-end yang lebih luas, seorang pengembang web seperti Amir Arezoo mungkin relevan untuk pekerjaan pengembangan website. Hal ini berbeda dari Capgo’s kontrol pengiriman yang menghandle pengiriman dan pemulihan untuk update aplikasi yang kompatibel.
Seharusnya, jalur rilis Anda sudah termasuk fallback stabil, pemilik, aturan berhenti, dan aksi pemulihan yang telah diuji. Pastikan alur kerja tetap singkat sehingga insinyur yang bertugas dapat menggunakannya di bawah tekanan.
FAQ
Apakah menghentikan Capgo rollout akan mengembalikan perangkat yang telah diperbarui?
Tidak. Menghentikan hanya akan mencegah perangkat yang baru layak untuk memasuki proses rollout, tetapi perangkat yang sudah dalam kelompok dapat tetap menggunakan bundle target. Untuk mengembalikan pengguna ke versi stabil, gunakan rollback atau aksi kanal lain yang sengaja. Periksa status kanal setelah perubahan, kemudian konfirmasikan hasilnya pada perangkat yang telah menerima bundle target.
Kapan saya harus menghentikan rollout daripada mengembalikan?
Menghentikan rollout ketika masalah masih dalam penyelidikan dan Anda membutuhkan untuk menghentikan paparan yang lebih luas. Mengembalikan ketika target diketahui akan merugikan pengguna atau ketika perangkat yang terkena membutuhkan bundle stabil. Pilihan menghentikan rollout vs mengembalikan Capgo bergantung pada apakah kebutuhan segera adalah kandungan atau pemulihan untuk kelompok yang sudah ada.
Apakah rollback akan memperbarui setiap perangkat segera?
Tidak. Rollback mengubah bundle yang dituju oleh kanal, tetapi perangkat menerima update ketika mereka memeriksa update berikutnya. Perangkat yang offline mungkin tetap menggunakan bundle saat ini hingga koneksi kembali. Periksa target kanal, kemudian periksa perangkat yang terkena dan status update mereka sebelum menyatakan insiden selesai.
Apakah rollback OTA dapat memperbaiki masalah aplikasi native?
Nomor. Rollback OTA dapat memulihkan update web bundle yang lebih awal, tetapi tidak dapat menambah atau menghapus native code di dalam aplikasi instalasi biner. Jika masalah berasal dari plugin atau perubahan app-shell native, tinjau apakah bangunan native baru diperlukan. Pertama-tama identifikasi lapisan yang menyebabkan gagal.
Apakah yang harus saya periksa setelah mematikan atau mengembalikan?
Konfirmasi status saluran dan bundle aktif, kemudian periksa pengadopsian update dan kesalahan oleh rilis. Uji perjalanan pengguna yang gagal pada perangkat dari kelompok yang terkena dampak. Juga periksa perangkat yang belum diperbarui, karena metrik keseluruhan dapat menyembunyikan masalah yang terbatas pada satu versi atau kelompok.
Kesimpulan
Berhenti ketika Anda membutuhkan untuk menghentikan paparan baru sementara Anda menyelidiki. Kembalikan ketika pengguna di target membutuhkan versi stabil. Atur kedua kontrol tersebut sebelumnya, kemudian latih mereka di saluran uji sebelum rilis produksi berikutnya.
