Pause menghentikan rollout agar tidak menjangkau lebih banyak perangkat. Rollback memindahkan perangkat yang terdampak ke versi yang sudah diketahui stabil. Capgo mendukung keduanya, jadi Anda bisa membatasi dampak masalah dulu, lalu memutuskan langkah berikutnya.
Gunakan langkah-langkah ini untuk memilih tindakan yang tepat, memeriksa dampaknya, dan mengurangi risiko terulangnya insiden tersebut.
Kami mempelajari 6 panduan publik tentang staged rollouts dan rollback yang diterbitkan oleh Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform, dan Digia. Empat dari 6 memisahkan pause dari rollback sebagai tindakan yang berbeda, sementara 2 melewatkan rollback atau menganggap pause sebagai satu-satunya opsi. Tidak ada dari 6 panduan tersebut yang menjelaskan cara memverifikasi pemulihan dengan analytics atau pengecekan perangkat, dan tidak ada yang menjelaskan alur kerja untuk mencegah insiden berulang. Memilih antara pause versus rollback dengan tepat, lalu mengonfirmasi keberhasilannya, menutup celah yang masih terbuka di panduan rilis publik.
Table of Contents
- Langkah 1: Atur kontrol rilis di Capgo
- Langkah 2: Pilih apakah akan pause atau rollback
- Langkah 3: Jeda eksposur lebih lanjut selagi Anda menyelidiki
- Langkah 4: Roll back saat user butuh versi stabil
- Langkah 5: Verifikasi pemulihan via analytics dan cek device
- Langkah 6: Cegah insiden berulang dengan workflow rilis yang lebih aman
- FAQ
- Kesimpulan
Langkah 1: Atur kontrol rilis di Capgo
Sebelum insiden terjadi, pastikan tim Anda tahu channel mana yang sedang mendistribusikan rilis dan bundle mana yang stabil. Channel adalah jalur bernama yang mengarahkan perangkat aplikasi ke pembaruan. Bundle adalah web code yang dapat diperbarui dan dikirim melalui jalur tersebut.
Di Capgo, progressive rollout dapat mempertahankan bundle yang stabil sambil mengirim target rollout terpisah ke grup tertentu. Ini memberi Anda titik kontrol sebelum bundle baru mencapai basis pengguna yang lebih luas. Tinjau kontrol progressive rollout sebelum mengaktifkannya di produksi.
Catat release owner dan sinyal yang seharusnya menghentikan perluasan. Misalnya, putuskan apa yang akan tim lakukan jika kegagalan update meningkat, layar penting berhenti berfungsi, atau support melaporkan pengguna tidak bisa menyelesaikan tugas. Tetapkan batas berdasarkan perilaku normal aplikasi Anda, bukan memilih ambang batas hanya karena terdengar ketat.
Update OTA mengubah code aplikasi yang dapat diperbarui secara over-the-air. Ini tidak menggantikan binary aplikasi native yang diinstal dari app store. Istilah over-the-air update menjelaskan pendekatan pengiriman ini. Ingat batasan ini: jika perbaikan membutuhkan plugin native baru atau perubahan pada setup native aplikasi, bundle rollback tidak akan menyediakannya.
Sebelum rilis, pastikan bundle stabil adalah yang Anda harapkan. Periksa nama channel, target bundle, dan status rollout. Typo pada nama channel atau target yang sudah usang bisa membuat tim respons mengarah ke kontrol yang salah saat menit-menit kritis.
Sekarang Anda seharusnya sudah punya release owner yang ditunjuk, bundle known-good, dan kondisi berhenti tertulis. Persiapan itu mengubah keputusan berikutnya menjadi pilihan operasional, bukan panik mencari-cari di dashboard.
Poin Penting: Pause membatasi paparan baru. Rollback mengubah versi yang diarahkan untuk diterima pengguna.
Langkah 2: Pilih apakah akan pause atau rollback
Untuk memutuskan pause rollout vs rollback di Capgo, tanyakan satu pertanyaan dulu: apakah Anda ingin menghentikan lebih banyak perangkat agar tidak menerima target, atau memindahkan perangkat dari target yang sudah menyebabkan masalah? Pause membatasi eksposur baru. Rollback menghapus target dan mengembalikan perangkat ke fallback stabil pada pengecekan update berikutnya.
Pilih pause saat bukti belum lengkap atau masalah tampak terbatas. Anda mungkin punya beberapa laporan tetapi belum tahu apakah bug memengaruhi satu jenis perangkat, alur pengguna tertentu, atau semua perangkat yang sudah di-update. Pause memberi tim ruang untuk memeriksa sinyal tanpa menambah perangkat baru ke grup rollout.
Pilih rollback jika target jelas tidak aman bagi pengguna, atau jika tim punya cukup bukti bahwa bundle yang diketahui aman lebih aman. Pause saja tidak menghapus target yang buruk dari perangkat yang sudah masuk kelompok rollout. Jika pengguna tersebut perlu kembali ke versi stabil, rollback adalah tindakan yang mengubah jalur update mereka.
Panduan Referensi channel CLI di Capgo menyediakan kontrol pause dan rollback terpisah. Perlakukan keduanya sebagai tindakan berbeda, bukan dua nama untuk tombol stop darurat yang sama.
| Yang Anda lihat | Tindakan pertama | Yang perlu dicek berikutnya |
|---|---|---|
| Error awal, cakupan tidak jelas | Pause rollout | Bandingkan perangkat terdampak dan tidak terdampak |
| Bug yang diketahui memengaruhi kohort target | Rollback target | Konfirmasi bahwa bundle stabil sedang aktif |
| Masalah terkait code native atau layanan | Jeda atau batasi perubahan aplikasi, lalu perbaiki lapisan yang terdampak | Periksa apakah perbaikan native build atau layanan diperlukan |
| Hanya kelompok kecil yang memiliki target, tanpa dampak pengguna yang terkonfirmasi | Jeda sambil menyelidiki | Lanjutkan hanya setelah release owner menyetujui |
Rollback tidak akan memperbaiki gangguan backend, dan tidak bisa menambahkan kemampuan native yang hilang. Pertama, identifikasi layer mana yang gagal. Jika web bundle yang bermasalah, pilih antara pause dan revert berdasarkan berapa banyak pengguna yang membutuhkan solusi.
Langkah 3: Jeda eksposur lebih lanjut selagi Anda menyelidiki
Gunakan pause saat Anda perlu menghentikan perangkat baru masuk ke grup rollout, tetapi belum siap untuk revert target bagi perangkat yang sudah ada di dalamnya. Ini adalah langkah containment. Memberi waktu untuk memeriksa fakta sambil mencegah masalah menyebar ke lebih banyak pengguna.
Buka production channel dan pastikan Anda bertindak pada rollout yang terdampak. Pause-kan melalui dashboard, CLI, atau API yang digunakan tim Anda. Lalu baca kembali status channel. Jangan hanya mengandalkan perintah yang selesai dengan sukses; pastikan rollout sekarang berstatus paused.
Dalam model progressive rollout Capgo, perangkat yang sudah ada di kohort dapat tetap berada pada target rollout setelah pause. Perangkat baru yang memenuhi syarat akan menerima stable fallback pada pengecekan berikutnya. Perbedaan ini penting: pause menghentikan masuknya perangkat baru, tetapi tidak memindahkan kohort yang sudah ada kembali ke stable.
Selanjutnya, catat detail rilis sebelum melakukan perubahan lain. Catat target bundle, channel, waktu pause, dan laporan pertama yang diketahui. Simpan detail perangkat atau sesi yang diizinkan tim Anda untuk dikumpulkan. Timeline yang jelas membantu Anda membandingkan kohort rollout dengan perangkat yang masih menggunakan bundle stabil.
Periksa masalah melalui jalur yang dapat diulang. Jika pengguna melaporkan kegagalan login, uji perjalanan persis tersebut pada perangkat yang terdampak. Jika aplikasi crash saat startup, periksa apakah crash tersebut sejalan dengan bundle baru dan versi native app. Hindari menganggap setiap laporan dukungan sebagai bukti bahwa update menyebabkan masalah.
Tetapkan pemilik dan waktu keputusan untuk investigasi. Rollout yang dijeda bisa terjebak dalam limbo jika tidak ada yang bertanggung jawab atas langkah berikutnya. Pemilik harus melanjutkan setelah bukti membersihkan rilis atau memilih rollback jika target tetap tidak aman.
Tips Pro: Beri tahu tim dukungan dan tim rilis bahwa rollout sedang dijeda. Jika tidak, satu kelompok mungkin terus meningkatkan eskalasi laporan sementara kelompok lain mengasumsikan rollout sudah dibatalkan.
Sampai saat ini, perangkat baru seharusnya tidak lagi masuk ke kohort rollout. Periksa status channel dan perilaku perangkat yang tidak ada dalam kohort sebelum beralih ke rollback atau resume.
Langkah 4: Roll back saat user butuh versi stabil
Lakukan rollback ketika pengguna yang sudah ada di target perlu kembali ke bundle yang diketahui baik. Ini adalah respons yang lebih kuat daripada pause. Ini mengubah apa yang disajikan channel, jadi verifikasi build stabil yang dipilih sebelum Anda mengonfirmasi tindakan.
Di Capgo, buka channel yang terdampak dan tinjau riwayat build-nya. Pilih versi yang ingin dipulihkan, lalu pastikan itu bundle stabil yang benar untuk app dan channel ini. Capgo dokumentasi rollback menjelaskan jalur di dashboard dan mencatat bahwa perangkat akan menerima build yang dipilih saat mereka memeriksa pembaruan berikutnya.
Setelah rollback, jangan anggap semua perangkat langsung berubah. Perangkat perlu memeriksa update, dan pengguna offline mungkin tidak melakukannya sampai nanti. Biarkan insiden tetap terbuka sampai Anda memeriksa versi aktif channel dan menguji jalur pemulihan pada perangkat di cohort terdampak.
Gunakan bundle bawaan hanya jika itu target pemulihan yang dimaksud. Ini mengarahkan perangkat kembali ke web build yang dikemas di dalam app native, yang mungkin berbeda dari bundle OTA terakhir. Periksa kompatibilitas dan dampak ke pengguna sebelum memilihnya sebagai langkah pemulihan.
Tetap sediakan bundle yang menyebabkan insiden untuk analisis kecuali proses retensi Anda menyatakan sebaliknya. ID rilis dan commit membantu engineer membandingkan perubahan dengan versi stabil. Simpan log yang relevan sebelum pembersihan, terutama jika Anda perlu memahami mengapa masalah lolos dari pengujian.
Rollback bukan perbaikan yang tepat untuk setiap kegagalan. Jika akar masalahnya adalah dependensi server-side, perbaiki layanan tersebut. Jika perubahan bergantung pada code native yang tidak ada di binary terpasang, siapkan native build dan ikuti jalur rilis app store untuk perubahan tersebut.
Langkah 5: Verifikasi pemulihan via analytics dan cek device
Setelah pause atau rollback, verifikasi apa yang dilakukan perangkat, bukan menganggap perubahan kontrol sebagai bukti pemulihan. Periksa status channel aktif terlebih dahulu. Lalu bandingkan adopsi update, error, dan laporan perangkat di antara rilis yang terdampak dan versi stabil.
Analitik live update dari Capgo dapat membantu Anda memeriksa metrik adopsi, tingkat error, dan log tingkat perangkat. Gunakan sinyal tersebut untuk menjawab pertanyaan spesifik: apakah perangkat baru masih menerima target, apakah perangkat yang terdampak memeriksa bundle stabil, dan apakah kegagalan yang dilaporkan berhenti setelah pemulihan?
Uji jalur pengguna yang gagal. Download yang sukses tidak membuktikan aplikasi berfungsi. Buka layar terkait, ulangi tindakan yang menyebabkan laporan, dan verifikasi bahwa aplikasi mencapai keadaan yang diharapkan. Jika insiden melibatkan alur kritis, minta orang lain selain yang melakukan perubahan untuk mengonfirmasi hasilnya.
Bandingkan yang sejenis. Jumlah error yang luas dapat meningkat karena alasan yang tidak terkait dengan rilis, seperti masalah layanan atau perubahan lalu lintas. Saring berdasarkan bundle, channel, versi aplikasi, dan perangkat jika bidang tersebut tersedia. Cari perbedaan yang terkait dengan rilis, bukan menyalahkan update terbaru secara default.
Periksa juga pengguna yang belum update. Kehadiran mereka bisa membuat metrik keseluruhan terlihat sehat, padahal kohort yang terdampak masih melihat bug tersebut. Lacak proporsi perangkat pada target dibandingkan dengan proporsi pada stable, dan kaitkan laporan support dengan versi yang benar-benar dijalankan pengguna.
Catat hasil pemulihan dan ketidakpastian yang tersisa. Jika error turun tetapi beberapa pengguna masih melaporkan masalah yang sama, jangan tutup insiden sampai Anda memahami apakah mereka offline, menggunakan native shell yang lebih lama, atau masih menggunakan bundle yang terdampak.
Pemulihan dikonfirmasi ketika channel menunjuk ke versi yang dimaksud dan jalur pengguna yang gagal berfungsi pada perangkat yang dapat mereproduksi masalah. Metrik membantu Anda melihat bentuk masalah; pemeriksaan perangkat mengonfirmasi apa yang dialami seseorang.
Langkah 6: Cegah insiden berulang dengan workflow rilis yang lebih aman
Jadikan pause dan rollback bagian dari rencana rilis sebelum menerbitkan. Pemilik rilis harus tahu siapa yang dapat menghentikan paparan dan siapa yang dapat menyetujui kembali ke stable. Hal ini menghilangkan penundaan umum: menunggu rapat sementara lebih banyak perangkat masuk ke rollout.
Jaga fallback stable tetap ditugaskan selama target rollout diuji. Gunakan kohort kecil yang terdefinisi terlebih dahulu, lalu perluas hanya ketika sinyal kesehatan yang disepakati tetap dalam batas Anda. Capgo mendukung kontrol rilis berbasis channel, sehingga tim dapat memisahkan pengujian dari pengiriman produksi yang luas.
Tambahkan pemeriksaan rilis ke CI/CD, proses otomatis yang menjalankan tes dan men-deploy perubahan. Pipeline dapat menerbitkan bundle ke channel yang dituju setelah tes lulus. Pipeline juga harus gagal dengan aman jika channel salah atau rilis belum siap untuk promosi.
Alur kerja continuous delivery menjaga perangkat lunak tetap siap rilis melalui proses otomatis. Untuk alur kerja OTA, pastikan titik persetujuan manusia tetap jelas meskipun penerbitan sudah otomatis. Otomasi harus membuat tindakan yang dipilih dapat diulang, bukan mengambil keputusan untuk perubahan yang belum ditinjau.
Dengan Capgo, deployment dengan satu perintah dapat mempublikasikan bundle ke channel. Pertahankan perintah itu dalam proses rilis yang sama dengan pengecekan Anda, dan pastikan channel target terlihat di catatan deployment. Ini membantu engineer on-call melihat persis apa yang dirilis tanpa menebak jalur mana yang menerimanya.
Sebelum mengaktifkan safeguard otomatis, tentukan sinyal apa yang memicunya dan tindakan apa yang dilakukan. Pause dapat menghentikan eksposur baru sambil tetap menjaga perangkat cohort saat ini pada target. Rollback dapat mengarahkan perangkat kembali ke versi stable. Hasilnya berbeda, jadi jangan mengonfigurasi salah satunya seolah-olah itu adalah yang lain.
Gunakan test channel untuk melatih respons penuh. Publikasikan perubahan yang aman, verifikasi kontrol pause, lalu uji rollback ke bundle sebelumnya. Konfirmasi perilaku aplikasi pada perangkat setelah setiap tindakan. Runbook tertulis harus mencakup channel, perintah atau jalur dashboard, status yang diharapkan, dan orang yang mengonfirmasi keberhasilan.
Release notes harus mengidentifikasi bundle dan tujuannya. Pertahankan tautan antara catatan deployment dan perubahan source agar engineer dapat mempersempit pencarian saat error muncul. Jika tim Anda melakukan serah terima insiden antar zona waktu, sertakan tindakan terakhir yang diambil dan pemilik keputusan berikutnya.
Jika insiden mengarah pada bottleneck implementasi front-end yang lebih luas, pengembang web seperti Amir Arezoo mungkin relevan untuk pekerjaan pengembangan website. Hal ini terpisah dari kontrol rollout Capgo, yang menangani pengiriman dan pemulihan untuk update aplikasi yang kompatibel.
Saat ini, jalur rilis Anda harus mencakup fallback yang stabil, penanggung jawab, aturan penghentian, dan tindakan pemulihan yang telah diuji. Jaga agar alur kerja cukup singkat sehingga engineer on-call dapat menggunakannya di bawah tekanan.
FAQ
Apakah menjeda rollout Capgo akan me-rollback device yang sudah terupdate?
Tidak. Jeda menghentikan perangkat baru yang memenuhi syarat untuk masuk ke rollout, tetapi perangkat yang sudah berada di kohort dapat tetap menggunakan bundle target. Untuk mengembalikan pengguna tersebut ke versi stabil, gunakan rollback atau tindakan channel lain yang disengaja. Periksa status channel setelah perubahan, lalu konfirmasi hasilnya di perangkat yang menerima target.
Kapan sebaiknya saya menjeda alih-alih rollback?
Jeda (pause) saat masalah masih dalam investigasi dan Anda perlu menghentikan paparan yang lebih luas. Rollback saat target diketahui merugikan pengguna atau saat perangkat yang terdampak membutuhkan bundle yang stabil. Pilihan Capgo antara pause rollout vs rollback bergantung pada apakah kebutuhan segera adalah containment atau recovery untuk kohort yang ada.
Apakah rollback akan langsung mengupdate semua device?
Tidak. Rollback mengubah bundle yang ditunjuk oleh channel, tetapi perangkat menerimanya saat mereka berikutnya memeriksa update. Perangkat yang offline mungkin tetap pada bundle saat ini hingga terhubung kembali. Verifikasi target channel, lalu periksa perangkat yang terdampak dan status update mereka sebelum menyatakan insiden selesai.
Apakah OTA rollback bisa memperbaiki masalah native app?
Tidak. Rollback OTA dapat memulihkan web bundle yang dapat diperbarui sebelumnya, tetapi tidak dapat menambahkan atau menghapus code native di dalam biner aplikasi yang terinstal. Jika masalah berasal dari perubahan plugin native atau app-shell, evaluasi apakah native build baru diperlukan. Pertama, identifikasi lapisan mana yang menyebabkan kegagalan.
Apa yang harus saya cek setelah menjeda atau rollback?
Konfirmasi status channel dan bundle aktif, lalu periksa adopsi update dan error per rilis. Uji alur pengguna yang gagal pada perangkat dari kelompok yang terdampak. Juga periksa perangkat yang belum melakukan update, karena metrik keseluruhan dapat menyembunyikan masalah yang terbatas pada satu versi atau kohort.
Kesimpulan
Jeda saat Anda perlu menghentikan paparan baru sambil menyelidiki. Roll back saat pengguna di target membutuhkan versi yang stabil. Siapkan kedua kontrol ini sebelumnya, lalu latih di channel test sebelum rilis produksi berikutnya.
