Rollbacks

Sementara Capgo memungkinkan Anda untuk memperbarui secara langsung dan memperbaiki kesalahan Anda, mungkin ada situasi di mana Anda perlu kembali ke versi sebelumnya dari aplikasi Anda. Mungkin update baru memperkenalkan masalah kritis yang tidak terduga, atau mungkin Anda ingin kembali ke perubahan tertentu sementara Anda bekerja pada solusi.

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

Pengamanan Kembali Otomatis

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

Judul bagian “Bagaimana Pengamanan Kembali Otomatis Berfungsi”

When a new update is downloaded and applied, Capgo expects your app to call notifyAppReady() Paket JavaScript dimuat tanpa kesalahan kritis

• __CAPGO_KEEP_0__
• Fungsi inti aplikasi Anda sedang berjalan
• Pembaruan ini aman untuk dipertahankan

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

1. Mendeteksi bahwa pembaruan gagal untuk diinisialisasi dengan benar
2. Mengembalikan secara otomatis ke bundle yang berfungsi sebelumnya
3. Mengidentifikasi pembaruan yang bermasalah sebagai gagal untuk mencegahnya dari diterapkan kembali

Tip

Pastikan untuk memanggil notifyAppReady() code di inisialisasi aplikasi Anda setelah komponen inti telah dimuat dengan sukses. Ini memastikan proteksi rollback otomatis berfungsi dengan benar.

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

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

Fungsi perlindungan 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

Anda dapat mengatur berapa lama Capgo menunggu notifyAppReady() untuk dipanggil dengan mengatur appReadyTimeout dalam konfigurasi Capacitor:

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

Nilai appReadyTimeout dihitung 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

Setiap kali Anda mengunggah build baru dan menugaskan ke saluran, Capgo menyimpan riwayat build tersebut. Jika Anda perlu mengembalikan pembaruan tertentu, Anda dapat memilih salah satu build sebelumnya untuk di-redeploy ke saluran.

Cara mengembalikan UI adalah melalui antarmuka pengembalian, yang terletak di tab ke-4 (Sejarah) ketika melihat sebuah saluran di Capgo Dashboard. Tab ini menyediakan tampilan komprehensif dari semua versi yang tersedia untuk saluran, memungkinkan Anda untuk dengan mudah memilih dan kembali ke versi sebelumnya.

Untuk mengembalikan menggunakan tab Sejarah:

1. Masuk ke Capgo Dashboard.

2. Navigasikan ke bagian "Saluran".

3. Klik nama saluran yang ingin Anda kembalikan.

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

5. Cari versi yang ingin Anda kembalikan ke dalam sejarah versi.

6. Pilih versi tersebut untuk membuatnya menjadi versi aktif untuk saluran.

7. Konfirmasi bahwa Anda ingin kembali ke versi ini.

Metode Alternatif: Menggunakan Ikon Mahkota

Dengan cara lain, Anda juga dapat mengembalikan secara langsung dari tab pertama dengan mengklik ikon mahkota di samping setiap build di sejarah build kanal:

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

Catatan

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

Setelah mengembalikan, perangkat yang dikonfigurasi untuk mendengarkan kanal yang diperbarui akan menerima build sebelumnya pada saat mereka memeriksa update berikutnya. Build yang dikembalikan akan dianggap sebagai update baru, sehingga aliran update dan kondisi biasa berlaku.

Menghilangkan Hubungan Kanal

Jika Anda ingin sementara menghentikan pembaruan di sebuah saluran sambil Anda menyelidiki masalah, Anda dapat melepas saluran dari build saat ini.

Untuk melepas saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

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

3. Konfirmasi bahwa Anda ingin melepas saluran.

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

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

Menggunakan Paket Built-In

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 “paket built-in”.

Untuk memaksa paket built-in di saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

2. Klik tombol “Built-in Bundle”.

3. Pastikan Anda ingin memaksa bundle bawaan.

Jika Anda memaksa bundle bawaan, semua perangkat yang terkonfigurasi pada saluran tersebut akan kembali ke versi web yang dikemas asli pada perangkat mereka pada saat mereka melakukan cek pembaruan berikutnya. Hal ini terjadi tanpa memandang versi apa yang mereka jalankan saat ini.

Pilihan rollback yang lebih agresif ini daripada kembali ke versi sebelumnya tertentu, karena membuang semua pembaruan hidup yang diterbitkan sejak aplikasi terakhir diterbitkan ke toko aplikasi.

Peringatan

Berhati-hatilah saat memaksa bundle bawaan, karena akan mempengaruhi semua perangkat pada saluran. Pastikan Anda telah mempertimbangkan dampaknya dan memiliki rencana untuk maju sebelum melakukan aksi ini.

Pengawasan dan Mengatasi Masalah

Untuk menangkap masalah dengan cepat dan meminimalkan dampak pembaruan yang bermasalah, penting untuk memiliki rencana untuk mengawasi rilis Anda dan mengatasi masalah.

Beberapa strategi termasuk:

• Mengawasi laporan kegagalan dan umpan balik pengguna segera setelah merilis pembaruan sebuah update
• Memanfaatkan peluncuran fase atau sistem saluran yang dipersiapkan untuk menguji pembaruan pada kelompok yang lebih kecil sebelum peluncuran luas
• Menggunakan proses keputusan yang jelas untuk mengetahui kapan harus mengembalikan, melepas, atau memaksa paket bawaan yang dibangun, serta siapa yang memiliki otoritas untuk melakukannya
• Komunikasi dengan pengguna tentang masalah dan solusi, jika perlu

Dengan kombinasi pemantauan yang hati-hati dengan kemampuan untuk mengelola pembaruan yang problematic dengan cepat, Anda dapat menyampaikan pengalaman aplikasi yang terus-menerus meningkat sambil mengurangi gangguan bagi pengguna Anda.

Teruskan dari Rollbacks

Jika Anda menggunakan Rollbacks untuk merencanakan pengembalian dan pengendalian versi, hubungkannya dengan Versi Targeting untuk detail implementasi di Versi Targeting, Pengaturan Pembaruan untuk detail implementasi di Update Behavior, bundle untuk detail implementasi di bundle, Capgo Live Updates untuk alur kerja produk di Capgo Live Updates, dan Strategi Rollback untuk Capacitor Live Updates untuk konteks praktis di Strategi Rollback untuk Capacitor Live Updates.