Rollback

Sementara Capgo’s live updates memungkinkan Anda untuk segera menyampaikan perbaikan dan perbaikan ke pengguna Anda, ada situasi di mana Anda mungkin perlu kembali ke versi sebelumnya dari aplikasi Anda. Mungkin update baru memperkenalkan masalah kritis yang tidak terduga, atau mungkin Anda ingin kembali perubahan tertentu sambil bekerja pada solusi.

Capgo menyediakan beberapa cara untuk mengelola bangunan saluran dan mengontrol versi aplikasi Anda yang diterima pengguna, termasuk baik opsi kembali manual dan mekanisme keamanan otomatis.

Pengamanan Kembali Otomatis

Capgo termasuk mekanisme keamanan bawaan untuk melindungi pengguna Anda dari update yang rusak. Jika terjadi kesalahan JavaScript sebelum metode dipanggil, plugin akan secara otomatis kembali ke versi kerja sebelumnya. notifyAppReady() Bagaimana Pengamanan Kembali Otomatis Berfungsi

Judul bagian “Bagaimana Pengamanan Kembali Otomatis Berfungsi”']}

Ketika pembaruan baru diunduh dan diterapkan, Capgo mengharapkan aplikasi Anda untuk memanggil notifyAppReady() dalam jangka waktu yang dapat disesuaikan untuk memastikan bahwa pembaruan tersebut berhasil di-load. Metode ini menandakan bahwa:

• Bundel JavaScript di-load tanpa adanya kesalahan kritis
• Fungsi inti aplikasi Anda berfungsi
• Pembaruan tersebut aman untuk disimpan

Jika notifyAppReady() tidak dipanggil karena crash JavaScript atau kesalahan kritis, Capgo akan:

1. Mendeteksi bahwa pembaruan gagal untuk diinisialisasi dengan benar
2. Mengembalikan secara otomatis ke bundle yang bekerja sebelumnya
3. Menandai pembaruan yang bermasalah sebagai gagal untuk mencegahnya dari aplikasi lagi

Tip

Pastikan untuk memanggil notifyAppReady() in your app’s initialization code after your core components have loaded successfully. This ensures the automatic rollback protection works as intended.

import { CapacitorUpdater } from '@capgo/capacitor-updater'

// Call this after your app has successfully initialized
await CapacitorUpdater.notifyAppReady()

Proteksi otomatis ini membantu memastikan bahwa bahkan jika Anda secara tidak sengaja mengirimkan pembaruan yang rusak, pengguna Anda tidak akan terjebak dengan aplikasi yang tidak berfungsi.

Mengatur Waktu Tunggu

You can configure how long Capgo waits for notifyAppReady() menunggu untuk dipanggil dengan mengatur appReadyTimeout in your Capacitor configuration:

{
  "plugins": {
    "CapacitorUpdater": {
      "appReadyTimeout": 10000
    }
  }
}

Nilai appReadyTimeout ditentukan dalam milidetik. Waktu tunggu default biasanya adalah 10 detik, tetapi Anda dapat menyesuaikan ini berdasarkan kebutuhan inisialisasi aplikasi Anda. Jika aplikasi Anda membutuhkan waktu lebih lama untuk dimuat karena proses inisialisasi yang kompleks, Anda mungkin ingin meningkatkan nilai ini.

Mengembalikan ke Versi Sebelumnya

Every time you upload a new build and assign it to a channel, Capgo keeps a history of those builds. If you need to revert a specific update, you can select one of these previous builds to redeploy to the channel.

The primary way to roll back is through the rollback interface, which is located in the 4th tab (History) when viewing a channel in the Capgo Dashboard. This tab provides a comprehensive view of all available builds for the channel, allowing you to easily select and revert to any previous version.

Untuk mengembalikan menggunakan tab Riwayat:

1. Masuk ke Capgo Dashboard.

2. Navigasikan ke bagian “Saluran”.

3. Klik nama saluran yang ingin Anda kembalikan.

4. Pergi ke tab ke-4 (Riwayat) di tampilan saluran.

5. Cari build yang ingin Anda kembalikan ke dalam riwayat build.

6. Pilih bangun untuk membuatnya menjadi bangunan aktif untuk saluran.

7. Konfirmasi bahwa Anda ingin kembali ke bangunan ini.

Metode Alternatif: Menggunakan Ikon Mahkota

Dengan cara lain, Anda juga dapat kembali langsung dari tab pertama dengan mengklik ikon mahkota di samping bangunan mana pun di sejarah bangunan saluran:

1. Dalam tab pertama tampilan saluran, cari bangunan yang ingin Anda kembali ke.
2. Klik ikon mahkota di samping bangunan tersebut untuk membuatnya menjadi bangunan aktif untuk saluran.
3. Konfirmasi bahwa Anda ingin kembali ke bangunan ini.

Catatan

Mengembalikan ke bangunan sebelumnya hanya akan mempengaruhi saluran yang dipilih. Jika Anda memiliki beberapa saluran (misalnya Produksi, Staging, dll.), Anda perlu mengulangi proses pengembalian ke bangunan untuk setiap saluran yang terpengaruh.

Setelah melakukan rollback, perangkat yang telah dikonfigurasi untuk mendengarkan saluran yang diperbarui akan menerima build sebelumnya pada saat mereka memeriksa pembaruan berikutnya. Build yang di-rollback akan dianggap sebagai pembaruan baru, sehingga alur pembaruan biasa dan kondisi yang berlaku.

Menghilangkan Saluran

Jika Anda ingin sementara menghentikan pembaruan pada saluran saat Anda menyelidiki masalah, Anda dapat menghilangkan saluran dari build saat ini.

Untuk menghilangkan saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

2. Klik tombol “Menghilangkan” di samping build saat ini.

3. Konfirmasi bahwa Anda ingin menghilangkan saluran.

Setelah saluran dihilangkan, saluran tidak akan mendistribusikan pembaruan baru. Perangkat yang dikonfigurasi untuk saluran tersebut akan tetap pada build saat ini hingga saluran dihubungkan ke build lagi.

Hal ini berguna jika Anda telah mengidentifikasi masalah dengan pembaruan tetapi belum yakin build mana yang ingin Anda rollback. Menghilangkan saluran memberikan waktu untuk menyelidiki tanpa memasarkan pembaruan lebih lanjut.

Menggunakan Paket Built-In dengan Paksa

Dalam situasi yang lebih parah, Anda mungkin ingin mengembalikan semua perangkat di saluran ke build web yang awalnya dikemas dengan binary native aplikasi Anda. Ini dikenal sebagai "bundle yang dibangun".

Untuk memaksa bundle yang dibangun pada saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

2. Klik tombol "Bundle yang Dibangun".

3. Pastikan Anda ingin memaksa bundle yang dibangun.

Ketika Anda memaksa bundle yang dibangun, semua perangkat yang dikonfigurasi untuk saluran tersebut akan kembali ke build web yang dikemas asli pada update cek berikutnya. Hal ini terjadi tanpa peduli build apa yang mereka jalankan saat ini.

Hal ini adalah opsi rollback yang lebih agresif daripada kembali ke build sebelumnya tertentu, karena menghilangkan semua update yang aktif yang dirilis sejak aplikasi terakhir diterbitkan ke toko aplikasi.

Peringatan

Berhati-hatilah ketika memaksa bundle yang dibangun, karena akan mempengaruhi semua perangkat di saluran. Pastikan Anda telah mempertimbangkan dampak dan memiliki rencana untuk maju sebelum mengambil tindakan ini.

Pengawasan dan Mengatasi Masalah

Untuk menangkap masalah dengan cepat dan meminimalkan dampak dari pembaruan yang bermasalah, penting untuk memiliki rencana untuk memantau rilis Anda dan merespons masalah.

Beberapa strategi termasuk:

• Mengawasi laporan kecelakaan dan umpan balik pengguna segera setelah merilis pembaruan
• Menggunakan peluncuran fase atau sistem saluran yang dipersiapkan untuk menguji pembaruan pada kelompok yang lebih kecil sebelum rilis luas
• Mempunyai proses keputusan yang jelas untuk ketika harus mengembalikan, melepas, atau memaksa paket yang dibangun secara bawaan, dan siapa yang memiliki otoritas untuk melakukannya
• Mengomunikasikan kepada pengguna tentang masalah dan solusi, jika perlu

Dengan menggabungkan pemantauan yang hati-hati dengan kemampuan untuk dengan cepat mengelola pembaruan yang bermasalah, Anda dapat menyampaikan pengalaman aplikasi yang terus-menerus meningkat sambil meminimalkan gangguan bagi pengguna Anda