Pause menghentikan rollout agar tidak mencapai lebih banyak perangkat. Rollback mengembalikan perangkat yang terdampak ke versi stabil yang sudah teruji. Capgo mendukung keduanya, jadi Anda bisa menangani masalah terlebih dahulu sebelum memutuskan langkah selanjutnya.
Gunakan langkah-langkah ini untuk memilih tindakan yang tepat, memeriksa efeknya, dan mengurangi risiko kejadian serupa terulang kembali.
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 panduan tersebut membedakan antara pausing dan rolling back sebagai tindakan yang berbeda, sementara 2 lainnya melewatkan rollback atau menganggap pause sebagai satu-satunya opsi. Tidak ada dari 6 panduan tersebut yang menjelaskan cara verifikasi pemulihan menggunakan analytics atau pengecekan perangkat, dan tidak ada yang menjelaskan workflow untuk mencegah insiden berulang. Memilih antara pause vs rollback dengan tepat, lalu mengonfirmasi keberhasilannya, akan menutup celah yang ada pada panduan rilis publik saat ini.
Table of Contents
- Langkah 1: Atur kontrol rilis di Capgo
- Langkah 2: Pilih untuk pause atau rollback
- Langkah 3: Pause eksposur lebih lanjut saat investigasi
- 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 aman
- FAQ
- Kesimpulan
Langkah 1: Atur kontrol rilis di Capgo
Sebelum insiden terjadi, pastikan tim Anda tahu channel mana yang mengirim rilis dan bundle mana yang stabil. Channel adalah jalur bernama yang mengarahkan device app ke sebuah update. Bundle adalah code web yang dapat di-update melalui jalur tersebut.
Di Capgo, progressive rollout dapat menjaga bundle stabil tetap berjalan sambil mengirim target rollout terpisah ke grup terpilih. Ini memberi Anda titik kontrol sebelum bundle baru mencapai basis user yang lebih luas. Tinjau kontrol progressive rollout sebelum mengaktifkannya di produksi.
Tentukan release owner dan sinyal yang harus menghentikan ekspansi. Misalnya, putuskan apa yang akan dilakukan tim jika kegagalan update meningkat, layar utama berhenti berfungsi, atau tim support melaporkan pengguna tidak bisa menyelesaikan tugas. Tetapkan batasan berdasarkan perilaku normal aplikasi Anda, bukan sekadar memilih ambang batas yang terdengar ketat.
Update OTA mengubah code aplikasi yang dapat diupdate secara over-the-air. Ini tidak mengganti binary native app yang diinstal dari app store. Istilah over-the-air update mendeskripsikan metode 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 usang dapat membuat tim salah mengambil tindakan saat waktu sangat krusial.
Sekarang Anda seharusnya sudah memiliki release owner, bundle yang teruji (known-good), dan kondisi penghentian tertulis. Persiapan tersebut mengubah keputusan berikutnya menjadi pilihan operasional, bukan kepanikan saat mencari-cari di dashboard.
Poin Penting: Pause membatasi paparan pengguna baru. Rollback mengubah versi yang diarahkan untuk diterima pengguna.
Langkah 2: Pilih antara pause atau rollback
Dalam memutuskan antara Capgo pause rollout vs rollback, ajukan satu pertanyaan: apakah Anda ingin mencegah lebih banyak perangkat menerima target tersebut, atau memindahkan perangkat dari target yang sudah terlanjur merugikan? Pause membatasi paparan baru. Rollback menghapus target tersebut dan mengembalikan perangkat ke fallback yang stabil pada pengecekan update berikutnya.
Pilih pause jika bukti belum lengkap atau masalah tampak terbatas. Anda mungkin menerima beberapa laporan tetapi belum tahu apakah bug tersebut memengaruhi satu tipe perangkat, alur pengguna tertentu, atau setiap 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 sudah punya cukup bukti bahwa bundle yang sudah teruji lebih aman. Pause saja tidak akan menghapus target yang buruk dari perangkat yang sudah masuk dalam kohort rollout. Jika pengguna tersebut perlu kembali ke versi stabil, rollback adalah tindakan yang mengubah jalur update mereka.
Skill channel Capgo referensi CLI menyediakan kontrol pause dan rollback yang terpisah. Perlakukan keduanya sebagai tindakan berbeda, bukan dua nama untuk satu tombol stop darurat yang sama.
| Apa yang Anda lihat | Tindakan pertama | Apa yang harus dicek selanjutnya |
|---|---|---|
| Error awal, cakupan tidak jelas | Pause rollout | Bandingkan perangkat yang terdampak dan tidak terdampak |
| Bug yang diketahui memengaruhi cohort target | Rollback target | Pastikan bundle stabil sudah aktif |
| Masalah terkait native code atau layanan | Pause atau batasi perubahan app, lalu perbaiki layer yang terdampak | Cek apakah perlu perbaikan native build atau layanan |
| Hanya grup kecil yang punya target, dan tidak ada dampak user yang terkonfirmasi | Pause selama investigasi | Resume hanya setelah disetujui release owner |
Rollback tidak akan memperbaiki backend outage, dan tidak bisa menambahkan native capability yang belum ada. Identifikasi dulu layer mana yang gagal. Jika masalahnya ada di web bundle, pilih antara pause atau revert berdasarkan berapa banyak user yang butuh penanganan.
Langkah 3: Pause eksposur lebih lanjut selama investigasi
Pause saat Anda perlu menghentikan perangkat baru masuk ke grup rollout, namun belum siap untuk mengembalikan target perangkat yang sudah ada di dalamnya. Ini adalah langkah containment untuk mengulur waktu guna mengecek fakta sambil mencegah masalah menyebar ke lebih banyak pengguna.
Buka channel produksi dan pastikan Anda menangani rollout yang terdampak. Pause melalui dashboard, CLI, atau API yang digunakan tim Anda. Kemudian cek kembali status channel tersebut. Jangan hanya mengandalkan perintah yang selesai dengan sukses; pastikan rollout memang sudah berstatus paused.
Dalam model progressive rollout Capgo, perangkat yang sudah ada di dalam cohort dapat tetap berada pada target rollout setelah proses pause. Perangkat baru yang memenuhi syarat akan menerima fallback stable pada pengecekan berikutnya. Perbedaan ini penting: pause menghentikan entri baru, tetapi tidak secara otomatis mengembalikan cohort yang ada ke versi stable.
Selanjutnya, catat detail rilis sebelum melakukan perubahan lain. Rekam target bundle, channel, waktu pause, dan laporan pertama yang diterima. Simpan detail perangkat atau sesi yang diizinkan untuk dikumpulkan tim Anda. Timeline yang jelas membantu Anda membandingkan cohort rollout dengan perangkat yang masih menggunakan bundle stable.
Cek masalah tersebut melalui jalur yang dapat direplikasi. Jika pengguna melaporkan gagal login, tes alur yang sama persis pada perangkat yang terdampak. Jika aplikasi crash saat dibuka, cek apakah crash tersebut sesuai dengan bundle baru dan versi native app. Jangan menganggap setiap laporan support sebagai bukti bahwa update tersebut adalah penyebab masalahnya.
Tentukan owner dan waktu pengambilan keputusan untuk investigasi. Rollout yang di-pause bisa terbengkalai jika tidak ada yang bertanggung jawab atas langkah selanjutnya. Owner harus segera resume setelah bukti menunjukkan rilis aman, atau memilih rollback jika target tetap tidak aman.
Tips Pro: Beri tahu tim support dan tim rilis bahwa rollout sedang di-pause. Jika tidak, satu tim mungkin terus menaikkan laporan sementara tim lain mengira rollout sudah di-rollback.
Pada tahap ini, perangkat baru seharusnya tidak lagi masuk ke cohort rollout. Cek status channel dan perilaku perangkat yang sebelumnya tidak ada di cohort sebelum memutuskan untuk rollback atau resume.
Langkah 4: Rollback saat user butuh versi stabil
Lakukan rollback jika user yang sudah menggunakan target perlu kembali ke bundle yang sudah terbukti aman. Ini adalah respons yang lebih kuat daripada sekadar pause. Karena ini mengubah isi channel, pastikan build stabil yang dipilih sudah benar sebelum konfirmasi.
Di Capgo, buka channel yang terdampak dan tinjau build history-nya. Pilih versi yang ingin dikembalikan, lalu pastikan itu adalah bundle stabil yang tepat untuk app dan channel ini. Capgo memiliki dokumentasi rollback yang menjelaskan alur di dashboard dan mencatat bahwa perangkat akan menerima build terpilih saat mereka melakukan pengecekan update berikutnya.
Setelah rollback, jangan berasumsi semua perangkat berubah seketika. Perangkat perlu melakukan pengecekan update, dan user offline mungkin baru melakukannya nanti. Biarkan insiden tetap terbuka sampai Anda memverifikasi versi aktif channel dan mengetes jalur recovery pada perangkat di cohort yang terdampak.
Gunakan built-in bundle hanya jika itu memang target pemulihan yang diinginkan. Ini akan mengarahkan perangkat kembali ke web build yang ada di dalam native app, yang mungkin berbeda dari bundle OTA terakhir. Cek kompatibilitas dan dampaknya ke user sebelum memilihnya sebagai langkah recovery.
Simpan bundle yang menyebabkan insiden untuk keperluan analisis kecuali jika proses retensi Anda menentukan lain. Release ID dan commit akan membantu engineer membandingkan perubahan dengan versi stabil. Simpan logs yang relevan sebelum cleanup, terutama jika Anda perlu memahami mengapa issue tersebut lolos dari testing.
Rollback bukan solusi tepat untuk setiap kegagalan. Jika root cause-nya adalah dependency di sisi server, perbaiki service tersebut. Jika perubahan bergantung pada native code yang tidak ada di binary yang terinstal, siapkan native build dan ikuti jalur rilis app store untuk perubahan tersebut.
Langkah 5: Verifikasi recovery dengan analytics dan pengecekan perangkat
Setelah pause atau rollback, verifikasi kondisi perangkat alih-alih menganggap perubahan kontrol sebagai bukti recovery. Cek status channel yang aktif terlebih dahulu. Kemudian bandingkan adopsi update, error, dan laporan perangkat antara release yang terdampak dengan versi stabil.
Analitik live update dari Capgo dapat membantu Anda memeriksa metrik adopsi, error rate, dan logs di level perangkat. Gunakan sinyal tersebut untuk menjawab pertanyaan spesifik: apakah perangkat baru masih menerima target, apakah perangkat yang terdampak mengecek bundle yang stabil, dan apakah kegagalan yang dilaporkan berhenti setelah pemulihan?
Uji user path yang gagal. Download yang berhasil bukan berarti aplikasi berjalan lancar. Buka layar terkait, ulangi aksi yang memicu laporan tersebut, dan verifikasi apakah aplikasi mencapai state yang diharapkan. Jika insiden melibatkan flow kritis, minta orang lain selain pengembang yang melakukan perubahan untuk mengonfirmasi hasilnya.
Bandingkan data yang setara. Jumlah error yang melonjak bisa disebabkan hal lain di luar rilis, seperti masalah layanan atau perubahan trafik. Filter berdasarkan bundle, channel, versi app, dan perangkat jika field tersebut tersedia. Cari perbedaan yang terkait langsung dengan rilis daripada langsung menyalahkan update terbaru.
Cek juga pengguna yang belum update. Kehadiran mereka bisa membuat metrik keseluruhan terlihat sehat padahal cohort yang terdampak masih mengalami bug. Pantau perbandingan jumlah perangkat pada target terhadap jumlah pada versi stabil, dan hubungkan laporan support dengan versi yang benar-benar dijalankan pengguna.
Catat hasil pemulihan dan ketidakpastian yang tersisa. Jika error menurun tetapi beberapa pengguna masih melaporkan masalah yang sama, jangan tutup insiden sampai Anda paham apakah mereka sedang offline, menggunakan native shell versi lama, atau masih menggunakan bundle yang terdampak.
Pemulihan terkonfirmasi saat channel mengarah ke versi yang dituju dan alur pengguna yang bermasalah berfungsi pada perangkat yang dapat mereproduksi isu tersebut. Metrik membantu Anda melihat pola masalah; pengecekan perangkat mengonfirmasi apa yang dialami pengguna.
Langkah 6: Cegah insiden berulang dengan workflow rilis yang lebih aman
Jadikan pause dan rollback bagian dari rencana rilis sebelum dipublikasikan. Pemilik rilis harus tahu siapa yang bisa menghentikan eksposur dan siapa yang bisa menyetujui kembali ke versi stable. Ini menghilangkan hambatan umum: menunggu rapat saat lebih banyak perangkat masuk ke rollout.
Siapkan fallback stable selama target rollout sedang diuji. Gunakan cohort kecil yang terdefinisi terlebih dahulu, lalu perluas hanya jika sinyal kesehatan yang disepakati tetap dalam batas Anda. Capgo mendukung kontrol rilis berbasis channel, sehingga tim dapat memisahkan pengujian dari pengiriman produksi secara luas.
Masukkan pengecekan rilis ke dalam CI/CD, proses otomatis yang menjalankan test dan deploy perubahan. Sebuah pipeline dapat mempublikasikan bundle ke channel yang dituju setelah test lulus. Pipeline juga harus gagal secara aman jika channel salah atau rilis belum siap untuk promosi.
Workflow continuous delivery menjaga software tetap siap rilis melalui proses otomatis. Untuk workflow OTA, pastikan titik persetujuan manusia tetap jelas meskipun publikasi sudah otomatis. Automasi harus membuat tindakan yang dipilih dapat diulang, bukan mengambil keputusan untuk perubahan yang belum direview.
Dengan Capgo, deployment satu perintah dapat mempublikasikan bundle ke sebuah channel. Masukkan perintah tersebut ke dalam proses rilis yang sama dengan pengecekan Anda, dan buat target channel terlihat di catatan deployment. Ini membantu engineer on-call melihat dengan tepat apa yang dirilis tanpa perlu menebak lane mana yang menerimanya.
Sebelum mengaktifkan safeguard otomatis, tentukan sinyal apa yang memicunya dan tindakan apa yang diambil. 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 seluruh respons. 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. Jaga hubungan 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 tersebut terpisah dari kontrol rollout Capgo, yang menangani pengiriman dan pemulihan untuk update aplikasi yang kompatibel.
Saat ini, alur rilis Anda seharusnya sudah mencakup fallback yang stabil, penanggung jawab, aturan penghentian, dan tindakan pemulihan yang teruji. Pastikan workflow cukup singkat agar engineer on-call dapat menggunakannya di bawah tekanan.
FAQ
Apakah menjeda rollout Capgo akan melakukan rollback pada perangkat yang sudah terupdate?
Tidak. Menjeda (pausing) akan menghentikan perangkat baru yang memenuhi syarat untuk masuk ke rollout, tetapi perangkat yang sudah berada di dalam cohort 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 pada perangkat yang telah menerima target tersebut.
Kapan saya harus menjeda (pause) alih-alih melakukan rollback?
Gunakan pause saat masalah masih dalam investigasi dan Anda perlu menghentikan eksposur yang lebih luas. Gunakan rollback saat target diketahui merugikan pengguna atau saat perangkat yang terdampak membutuhkan bundle yang stabil. Pilihan antara Capgo pause rollout vs rollback bergantung pada apakah kebutuhan mendesaknya adalah containment atau recovery bagi cohort yang sudah ada.
Apakah rollback akan langsung mengupdate setiap perangkat?
Tidak. Rollback mengubah bundle yang dituju oleh channel, tetapi perangkat baru akan menerimanya saat mereka melakukan pengecekan update berikutnya. Perangkat yang sedang offline mungkin akan tetap pada bundle saat ini sampai terhubung kembali. Verifikasi target channel, lalu periksa perangkat yang terdampak beserta status update-nya sebelum menyatakan insiden telah selesai.
Bisakah OTA rollback memperbaiki masalah pada native app?
Catatan: OTA rollback dapat mengembalikan web bundle versi sebelumnya, tetapi tidak bisa menambah atau menghapus native code di dalam binary aplikasi yang sudah terinstal. Jika masalah berasal dari native plugin atau perubahan app-shell, nilai apakah perlu Native Build baru. Identifikasi dulu layer mana yang menyebabkan kegagalan.
Apa yang harus saya periksa setelah melakukan pause atau rollback?
Konfirmasi status channel dan bundle yang aktif, lalu cek adopsi update dan error per rilis. Tes user journey yang gagal pada perangkat dari grup yang terdampak. Cek juga perangkat yang belum update, karena metrik keseluruhan bisa menyembunyikan masalah yang hanya terjadi pada satu versi atau kohort tertentu.
Kesimpulan
Gunakan Pause saat Anda perlu menghentikan eksposur baru selama investigasi. Gunakan Rollback saat pengguna di target perlu versi yang stabil. Siapkan kedua kontrol ini sebelumnya, lalu coba di test channel sebelum rilis produksi berikutnya.
