Pause akan menghentikan rollout dari mencapai lebih banyak perangkat. Rollback akan mengarahkan perangkat yang terkena ke versi yang sudah diketahui baik. Capgo supports both, so you can contain a problem first and decide what to do next.
Ikuti langkah-langkah ini untuk memilih aksi yang tepat, memeriksa efeknya, dan mengurangi kemungkinan terulangnya insiden tersebut.
Kami membaca 6 panduan publik tentang rollouts yang dipasang 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 mengabaikan rollback atau menganggap pause sebagai satu-satunya pengaturan. Tidak ada dari 6 yang menjelaskan cara memverifikasi pemulihan dengan analitik atau periksa perangkat, dan tidak ada yang menjelaskan alur kerja untuk mencegah insiden yang sama berulang. Mendapatkan pilihan pause-versus-rollback yang tepat, kemudian memastikan bahwa itu berhasil, menutup celah yang ditinggalkan di seluruh panduan rilis publik.
Tabel Konten
- Step 1: Set up release controls in Capgo
- Langkah 2: Pilih apakah untuk pause atau rollback
- Langkah 3: Pause eksposi lebih lanjut sementara Anda menyelidiki
- Langkah 4: Roll back ketika pengguna membutuhkan versi yang stabil
- Langkah 5: Verifikasi pemulihan dengan analitik dan periksa perangkat
- Langkah 6: Mencegah insiden yang sama dengan alur pelepasan yang lebih aman
- FAQ
- Kesimpulan
Langkah 1: Atur kontrol pelepasan di Capgo
Pastikan tim Anda mengetahui saluran mana yang menyampaikan pelepasan dan paket mana yang stabil sebelum insiden terjadi. Saluran adalah jalur yang dinamai yang mengarahkan perangkat aplikasi ke update. Paket adalah web code yang dapat diperbarui yang dikirim melalui jalur tersebut.
Dalam Capgo, peluncuran progresif dapat mempertahankan paket stabil di tempat sambil mengirimkan target peluncuran terpisah ke kelompok yang dipilih. Ini memberikan titik kontrol sebelum paket baru mencapai basis pengguna yang lebih luas. Tinjau kontrol peluncuran progresif sebelum mengaktifkannya di produksi. pengendalian peluncuran progresif sebelum mengaktifkannya di produksi.
Write down the release owner and the signals that should stop expansion. For example, decide what your team will do if update failures rise, a key screen stops working, or support reports that users can’t finish a task. Set limits based on your app’s normal behavior rather than picking a threshold just because it sounds strict.
An OTA update changes the app’s updateable code over the air. It doesn’t replace the native app binary installed from an app store. The term over-the-air update describes this delivery approach. Keep this boundary in mind: if a fix needs a new native plugin or a change to the app’s native setup, a bundle rollback won’t supply it.
Sebelum rilis, pastikan bundle stabil yang Anda harapkan. Periksa nama saluran, bundle target, dan status peluncuran. Salah ketik nama saluran atau target yang ketinggalan dapat mengarahkan pengguna ke kontrol yang salah ketika waktu sangat penting.
Pada saat ini, Anda seharusnya telah memiliki pemilik rilis yang diberi nama, bundle yang diketahui baik, dan kondisi berhenti yang ditulis. Persiapan tersebut mengubah keputusan selanjutnya menjadi pilihan operasional, bukan kebingungan melalui dashboard.
Kunci Pemahaman: Paus membatasi paparan baru. Rollback mengubah versi yang pengguna diarahkan untuk menerima.
Langkah 2: Pilih apakah Anda ingin membatalkan atau mengembalikan
For the Capgo pause rollout vs rollback decision, ask one question first: are you trying to stop more devices from getting the target, or move devices off a target that’s already causing harm? A pause limits new exposure. A rollback clears the target and returns devices to the stable fallback on their next update check.
Choose pause when evidence is incomplete or the issue appears limited. You may have a handful of reports but not know whether the bug affects one device type, a particular user flow, or every updated device. Pausing gives the team room to inspect the signal without adding new devices to the rollout group.
Pilih rollback ketika target jelas tidak aman bagi pengguna, atau ketika tim memiliki bukti yang cukup bahwa bundle yang diketahui baik lebih aman. Hentikan saja tidak menghilangkan target yang buruk dari perangkat yang sudah dalam kelompok rollout. Jika pengguna tersebut perlu kembali ke stabil, rollback adalah aksi yang mengubah jalur pembaruan mereka.
The Saluran Capgo CLI referensi Daftar kontrol pause dan rollback terpisah. Tatalah mereka sebagai aksi yang berbeda, bukan dua nama untuk berhenti darurat yang sama.
| Apa yang Anda lihat | Aksi pertama | Apa yang perlu diperiksa selanjutnya |
|---|---|---|
| Kesalahan awal, ruang lingkup tidak jelas | Apa yang perlu Anda periksa selanjutnya | Kesalahan awal, ruang lingkup tidak jelas |
| Masalah yang diketahui mempengaruhi kelompok target | Mengembalikan Target | Konfirmasi bahwa bundle 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 kegagalan backend, dan tidak dapat menambahkan kemampuan native yang hilang. Pertama-tama identifikasi layer mana yang gagal. Jika bundle web yang bersalah, pilih antara pause dan kembali berdasarkan berapa banyak pengguna yang membutuhkan relaksasi.
Langkah 3: Pause ekspose lebih lanjut sementara Anda menyelidiki
Pause when you need to stop new devices from entering the rollout group but aren’t ready to revert the target for devices already in it. This is a containment step. It buys time to check the facts while keeping the issue from spreading to more users.
Open the production channel and verify that you’re acting on the affected rollout. Pause it with the dashboard, CLI, or API control your team uses. Then read the channel state back. Don’t rely only on a command completing successfully; confirm the rollout now shows as paused.
Di model peluncuran progresif Capgo, perangkat yang sudah ada di kelompok dapat tetap pada target peluncuran setelah dihentikan. Perangkat baru yang layak menerima fallback stabil pada cek berikutnya. Perbedaan ini penting: hentikan pause menghentikan masuk baru, tetapi 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 diizinkan untuk mengumpulkan. Garis waktu yang jelas membantu Anda membandingkan kelompok peluncuran dengan perangkat yang masih menggunakan bundle stabil.
Periksa 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 peluncuran, periksa apakah crash tersebut sesuai dengan bundle baru dan versi aplikasi native. Hindari menganggap setiap laporan dukungan sebagai bukti bahwa pembaruan menyebabkan masalah.
Setel pemilik dan waktu keputusan untuk penyelidikan. Peluncuran yang dihentikan dapat berada di ambang kehancuran jika tidak ada yang mengambil langkah selanjutnya. Pemilik harus mengaktifkan kembali setelah bukti membuktikan rilis aman atau memilih rollback ketika target tetap tidak aman.
Tips Pro: Informasikan dukungan dan tim rilis bahwa peluncuran telah dihentikan. Jika tidak, satu kelompok mungkin terus mengangkat laporan sementara kelompok lain menganggap peluncuran telah dibalik.
Seharusnya perangkat baru tidak lagi masuk dalam kelompok rollout. Periksa status saluran dan perilaku perangkat yang tidak pernah masuk dalam kelompok sebelum melanjutkan ke rollback atau resume.
Langkah 4: Roll back ketika pengguna membutuhkan versi stabil
Roll back ketika pengguna sudah menggunakan versi target dan perlu kembali ke bundle yang diketahui baik. Ini adalah respons yang lebih kuat daripada mematikan. Ini mengubah apa yang disajikan oleh saluran, jadi pastikan versi stabil yang dipilih sebelum mengonfirmasi aksi.
Dalam Capgo, buka saluran yang terkena dampak dan tinjau riwayat buildnya. Pilih versi yang ingin Anda kembalikan, lalu pastikan itu adalah bundle stabil yang tepat untuk aplikasi dan saluran ini. Capgo’s membahas dokumentasi rollback Menggambarkan jalur dashboard dan mencatat bahwa perangkat menerima build yang dipilih pada saat mereka memeriksa pembaruan berikutnya.
Setelah rollback, jangan asumsikan perangkat semua berubah sekaligus. Perangkat perlu memeriksa update, dan pengguna offline mungkin tidak melakukannya sampai kemudian. Biarkan insiden tetap terbuka sampai Anda telah memeriksa versi aktif saluran dan menguji jalur pemulihan pada perangkat dalam kelompok yang terkena dampak.
Pilih bundle bawaan hanya ketika itu adalah target pemulihan yang dimaksud. Ini mengarahkan perangkat kembali ke build web yang dikemas dalam aplikasi native, yang mungkin berbeda dari bundle OTA terakhir. Periksa kompatibilitas dan dampak pengguna sebelum memilih langkah pemulihan ini.
Jika tidak ada instruksi untuk menghapusnya, simpan bundle yang menyebabkan insiden untuk analisis. ID rilis dan commit membantu insinyur membandingkan perubahan dengan versi stabil. Simpan log yang relevan sebelum membersihkan, terutama jika Anda perlu memahami mengapa masalah melintasi pengujian.
Rollback is not the right fix for every failure. If the root cause is a server-side dependency, repair that service. If the change depends on native code absent from installed binaries, prepare a native build and follow the app store release path for that change.
Langkah 5: Verifikasi pemulihan dengan analisis dan pengecekan 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 can help you inspect adoption metrics, error rates, and device-level logs. Use those signals to answer specific questions: are new devices still receiving the target, are affected devices checking for the stable bundle, and did the reported failure stop after recovery?
Tes jalur pengguna yang gagal. Download sukses tidak membuktikan aplikasi berfungsi. Buka layar relevan, ulangi aksi yang menyebabkan laporan, dan verifikasi aplikasi mencapai keadaan yang diharapkan. Jika insiden melibatkan alur kritis, minta orang lain selain orang yang membuat perubahan memastikan hasilnya.
Bandingkan yang sama dengan yang sama. Jumlah kesalahan luas mungkin meningkat karena alasan yang tidak terkait dengan rilis, seperti masalah layanan atau perubahan lalu lintas. Filter berdasarkan paket, saluran, versi aplikasi, dan perangkat di mana bidang-bidang tersebut 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 pada target terhadap bagian pada stabil, dan jaga laporan dukungan terkait dengan versi yang digunakan pengguna.
Tulis 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 asli yang lebih tua, atau masih menggunakan paket yang terkena.
Pemulihan dikonfirmasi ketika saluran menunjuk ke versi yang diinginkan dan jalur pengguna yang gagal berfungsi pada perangkat yang dapat mereproduksi masalah. Metrik membantu Anda melihat bentuk masalah; periksa perangkat untuk memastikan apa yang dialami orang.
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 tahu siapa yang dapat menghentikan paparan dan siapa yang dapat menyetujui kembali ke kondisi stabil. Hal ini menghilangkan hambatan umum: menunggu pertemuan sambil lebih banyak perangkat memasuki proses rollout.
Simpan fallback stabil yang ditugaskan sementara target rollout diuji. Gunakan kelompok kecil yang ditentukan pertama, kemudian luaskan hanya ketika signal kesehatan yang disepakati tetap dalam batas-batas Anda. Capgo mendukung pengendalian rilis berdasarkan channel, sehingga tim dapat memisahkan pengujian dari pengiriman produksi yang luas.
Masukkan periksa rilis ke CI/CD, proses otomatis yang menjalankan tes dan mengdeploy perubahan. Pipa dapat mempublikasikan bundle ke channel yang dituju setelah tes berhasil. Pipa juga harus gagal dengan aman jika channel yang salah atau rilis tidak siap untuk promosi.
Aliran pengiriman terus-menerus menjaga perangkat lunak siap untuk rilis melalui proses otomatis. Untuk aliran OTA, pastikan titik persetujuan manusia tetap jelas meskipun publikasi yang otomatis. Otomatisasi harus membuat aksi yang dipilih dapat diulang, bukan membuat keputusan untuk perubahan yang belum direview.
Dengan Capgo, pengiriman satu perintah dapat mempublikasikan bundle ke channel. Simpan perintah tersebut dalam proses rilis yang sama dengan periksa Anda, dan pastikan channel target yang dituju terlihat dalam rekaman pengiriman. Hal ini membantu insinyur yang bertugas siang malam 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 perangkat yang saat ini berada di kohort tetap berada di target. Rollback dapat mengarahkan perangkat ke versi stabil. Keduanya memiliki hasil yang 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 mengonfirmasi kesuksesan.
Catatan rilis harus mengidentifikasi bundle dan tujuan. Simpan link antara rekaman 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 itu berbeda dari pengaturan Capgo rollout, yang mengelola pengiriman dan pemulihan untuk pembaruan aplikasi yang kompatibel.
Seharusnya, jalur rilis Anda sudah mencakup 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 rollout Capgo akan mengembalikan perangkat yang telah diperbarui?
Nomor. Menghentikan memblokir perangkat baru yang layak untuk memasuki peluncuran, tetapi perangkat yang sudah ada dalam kelompok dapat tetap menggunakan paket target. Untuk mengembalikan pengguna ke arah stabil, gunakan rollback atau aksi kanal lain yang sengaja. Periksa status kanal setelah perubahan tersebut, kemudian konfirmasikan hasilnya pada perangkat yang menerima target.
Mengapa saya harus menghentikan alih-alih mengembalikan?
Menghentikan ketika masalah masih dalam penyelidikan dan Anda membutuhkan untuk menghentikan paparan yang lebih luas. Kembalikan ketika target diketahui menyebabkan kerusakan pada pengguna atau ketika perangkat yang terkena membutuhkan paket stabil. Pilihan menghentikan vs mengembalikan Capgo bergantung pada apakah kebutuhan segera adalah pengendalian atau pemulihan untuk kelompok yang ada.
Apakah update kembalikan akan memperbarui perangkat setiap saat?
Tidak. Mengembalikan mengubah paket yang ditunjuk oleh kanal, tetapi perangkat menerima update ketika mereka memeriksa update berikutnya. Perangkat yang offline mungkin tetap menggunakan paket saat ini hingga koneksi kembali. Verifikasi target kanal, kemudian periksa perangkat yang terkena dan status update mereka sebelum menyatakan insiden selesai.
Apakah rollback OTA dapat memperbaiki masalah aplikasi native?
Tidak. Rollback OTA dapat memulihkan paket web yang lebih awal yang dapat diperbarui, tetapi tidak dapat menambahkan atau menghapus plugin atau aplikasi native code di dalam file biner aplikasi yang terpasang. Jika masalah berasal dari perubahan plugin atau aplikasi native, tinjau apakah pembangunan native baru diperlukan. Pertama-tama identifikasi lapisan yang menyebabkan gagal.
Apa yang harus saya periksa setelah menghentikan atau mengembalikan?
Konfirmasikan status saluran dan bundle aktif, lalu periksa adopsi dan kesalahan update 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
Jeda ketika Anda perlu menghentikan paparan baru sementara Anda menyelidiki. Kembali ke versi stabil ketika pengguna target memerlukan versi yang stabil. Atur kedua kontrol tersebut sebelumnya, lalu latih mereka pada saluran uji sebelum rilis produksi berikutnya.
