Mengembalikan

Sementara Capgo memungkinkan Anda untuk memperbarui secara langsung dan menyampaikan perbaikan dan perbaikan kepada pengguna, 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 mengembalikan perubahan tertentu sambil bekerja pada solusi.

Capgo menyediakan beberapa cara untuk mengelola bangunan saluran dan mengontrol versi aplikasi yang diterima oleh pengguna, termasuk pilihan rollback manual dan mekanisme keamanan otomatis.

Pengembalian Otomatis Ke Versi Sebelumnya

Capgo termasuk mekanisme keamanan bawaan untuk melindungi pengguna Anda dari pembaruan yang rusak. Jika terjadi kesalahan JavaScript sebelum aplikasi dijalankan, notifyAppReady() Jika metode ini dipanggil, plugin akan secara otomatis kembali ke versi kerja sebelumnya.

Bagaimana Cara Rollback Otomatis Berfungsi

Ketika sebuah update baru diunduh dan diterapkan, Capgo mengharapkan aplikasi Anda untuk memanggil notifyAppReady() Dalam jangka waktu yang dapat disesuaikan untuk memastikan bahwa pembaruan telah dimuat dengan sukses. Metode ini menandakan bahwa:

• Bundel JavaScript dimuat tanpa adanya kesalahan kritikal
• Fungsi inti aplikasi Anda sedang berjalan
• Pembaruan ini aman untuk tetap dipertahankan

Jika notifyAppReady() Jika terjadi crash atau kesalahan kritis JavaScript, maka Capgo akan:

1. Deteksi bahwa pembaruan gagal diinisialisasi dengan benar
2. Mengembalikan secara otomatis ke bundle kerja sebelumnya
3. Tandai update yang bermasalah sebagai gagal untuk mencegahnya dari diterapkan lagi

Trik

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

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

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

Pelindung 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 sebelum notifyAppReady() untuk dipanggil dengan mengatur appReadyTimeout dalam konfigurasi Capacitor Anda:

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

The appReadyTimeout nilai ditentukan dalam milidetik. Waktu tunggu default biasanya 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.

Kembali ke Versi Sebelumnya

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

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

Untuk mengembalikan menggunakan tab Sejarah:

1. Masuk ke Dashboard __CAPGO_KEEP_0__ Capgo Dashboard.

2. Klik nama saluran yang ingin Anda kembalikan.

3. Lihat tab ke-4 (Sejarah) di tampilan saluran.

4. Cari build yang ingin Anda kembalikan ke dalam sejarah build.

5. Pilih build tersebut untuk membuatnya menjadi build aktif untuk saluran.

6. Konfirmasi bahwa Anda ingin kembali ke build ini.

7. Metode Alternatif: Menggunakan Ikon Mahkota

Judul bagian “Metode Alternatif: Menggunakan Ikon Mahkota”

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

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

Catatan

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

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

Menghilangkan Saluran

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

Untuk menghilangkan saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

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

3. Konfirmasikan bahwa Anda ingin melepaskan saluran.

Setelah sebuah saluran dihilangkan, tidak akan ada pembaruan baru yang didistribusikan. Perangkat yang dikonfigurasi ke saluran tersebut akan tetap menggunakan versi saat ini hingga saluran tersebut dihubungkan ke versi baru lagi.

Jika Anda telah mengidentifikasi masalah dengan update tetapi belum yakin ingin kembali ke build mana, maka menghilangkan saluran ini memberikan waktu untuk menyelidiki tanpa mengirimkan update lebih lanjut.

Menggunakan Paket yang Dibangun Secara Otomatis

Dalam situasi yang lebih parah, Anda mungkin ingin mengembalikan semua perangkat di saluran ke versi web yang asli yang dikemas bersama dengan biner native aplikasi Anda. Ini dikenal sebagai "bundle bawaan".

Untuk memaksa bundle yang sudah dibangun pada saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

2. Klik tombol “Built-in Bundle”.

3. Konfirmasikan bahwa Anda ingin memaksa pembundelan bawaan.

Jika Anda memaksa bundel bawaan, semua perangkat yang dikonfigurasi ke saluran tersebut akan kembali ke pembangunan web asli yang dikemas pada pembaruan selanjutnya. Hal ini terjadi tanpa memandang versi apa yang mereka gunakan saat ini.

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

Peringatan

Berhati-hatilah ketika memaksa bundel bawaan, 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 pembaruan yang bermasalah, penting untuk memiliki rencana untuk mengawasi rilis dan mengatasi masalah.

Beberapa strategi termasuk:

• Mengawasi laporan kegagalan dan umpan balik pengguna segera setelah merilis pembaruan
• Menggunakan peluncuran fase atau sistem saluran yang dipasang untuk menguji pembaruan pada kelompok yang lebih kecil sebelum peluncuran luas
• Mempunyai proses keputusan yang jelas untuk ketika harus mengembalikan, melepaskan, atau memaksa bundel bawaan, dan siapa yang memiliki otoritas untuk melakukannya
• Mengkomunikasikan kepada pengguna tentang masalah dan solusi, jika perlu

Dengan menggabungkan pemantauan yang hati-hati dengan kemampuan untuk segera mengelola update yang problematic, Anda dapat menyampaikan pengalaman aplikasi yang terus-menerus membaik sambil mengurangi gangguan bagi pengguna Anda.