Rollback

Sementara Capgo memungkinkan Anda untuk memperbarui secara langsung dan memperbaiki kesalahan Anda dengan cepat, 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 Anda bekerja pada solusi.

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

Pengamanan Rollback Otomatis

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

Bagian berjudul “Bagaimana Cara Kerja Rollback Otomatis”

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

• Fungsi inti aplikasi Anda berfungsi dengan baik
• Pembaruan aman untuk dipertahankan
• Jika

tidak dipanggil karena crash JavaScript atau kesalahan kritis, __CAPGO_KEEP_0__ akan: notifyAppReady() is not called due to a JavaScript crash or critical error, Capgo will:

1. Cloudflare, Capacitor, GitHub, Capgo, code, API, SDK, CLI, npm, bun
2. Otomatis kembali ke bundle yang berfungsi sebelumnya
3. Tandai update yang bermasalah sebagai gagal untuk mencegahnya dari diterapkan lagi

Tip

Pastikan Anda memanggil notifyAppReady() di inisialisasi aplikasi Anda code setelah komponen inti Anda 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()

Pengamanan otomatis ini membantu memastikan bahwa bahkan jika Anda secara tidak sengaja menerapkan update 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 menetapkan appReadyTimeout Ini konfigurasi Capacitor Anda:

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

Bagian appReadyTimeout Nilainya 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.

Mengembalikan ke Versi Sebelumnya

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

Cara utama untuk mengembalikan adalah melalui antarmuka pengembalian, yang terletak di tab ke-4 (Riwayat) ketika Anda 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 Riwayat:

1. Masuk ke Dashboard Capgo.

2. Navigasikan ke bagian “Saluran”.

3. Klik nama saluran yang ingin Anda kembali.

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

5. Temukan build yang ingin Anda kembalikan ke dalam sejarah build.

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

7. Konfirmasi bahwa Anda ingin kembali ke build ini.

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 kembalikan.
2. Klik ikon mahkota di samping build tersebut untuk membuatnya menjadi build aktif untuk saluran.
3. Konfirmasi bahwa Anda ingin kembali ke versi ini.

Catatan

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

Setelah mengembalikan ke versi sebelumnya, perangkat yang dikonfigurasi untuk mendengarkan saluran yang diperbarui akan menerima versi sebelumnya saat mereka memeriksa update berikutnya. Versi yang dikembalikan akan dianggap sebagai update baru, sehingga alur update dan kondisi biasa berlaku.

Menghilangkan Saluran

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

Untuk menghilangkan saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

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

3. Konfirmasi bahwa Anda ingin menghilangkan saluran.

Setelah sebuah saluran dihilangkan, tidak akan menyebarluaskan pembaruan apa pun yang baru. Perangkat yang dikonfigurasi untuk saluran tersebut akan tetap pada bangunannya saat ini hingga saluran tersebut terhubung ke bangunan lagi.

Fitur ini berguna jika Anda telah mengidentifikasi masalah dengan pembaruan tetapi belum yakin ingin kembali ke bangunan mana. Menghilangkan saluran memberikan waktu untuk menyelidiki tanpa membagikan pembaruan yang lebih lanjut.

Memaksa Paket Dalam

Dalam situasi yang lebih parah, Anda mungkin ingin kembali semua perangkat pada saluran ke bangunan web yang awalnya dikemas dengan biner native aplikasi Anda. Ini dikenal sebagai “paket dalam”.

Untuk memaksa paket dalam pada saluran:

1. Navigasikan ke saluran di Capgo Dashboard.

2. Klik tombol “Paket Dalam”.

3. Konfirmasi bahwa Anda ingin memaksa paket dalam.

Ketika Anda memaksa paket dalam, semua perangkat yang dikonfigurasi untuk saluran tersebut akan kembali ke bangunan web asli yang dikemas pada bangunan berikutnya. Hal ini terjadi tanpa peduli bangunan apa yang mereka gunakan saat ini.

Fitur ini adalah opsi kembali yang lebih agresif daripada kembali ke bangunan sebelumnya tertentu, karena membuang semua pembaruan hidup yang dirilis sejak aplikasi terakhir diterbitkan ke toko aplikasi.

Peringatan

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

Pengawasan dan Tanggapan Masalah

Untuk menangkap masalah dengan cepat dan meminimalkan dampak dari update yang bermasalah, penting untuk memiliki rencana untuk mengawasi rilis Anda dan menanggapi masalah.

Beberapa strategi termasuk:

• Mengawasi laporan kegagalan dan umpan balik pengguna secara langsung setelah merilis update
• Menggunakan peluncuran fase atau sistem saluran yang dipersiapkan untuk menguji update pada kelompok yang lebih kecil sebelum peluncuran luas
• Mempunyai proses keputusan yang jelas untuk ketika harus mengembalikan, melepas, atau memaksa bundle bawaan, dan siapa yang memiliki wewenang untuk melakukannya
• Mengkomunikasikan kepada pengguna tentang masalah dan solusi, jika perlu

Dengan menggabungkan pengawasan yang hati-hati dengan kemampuan untuk segera mengelola update yang bermasalah, Anda dapat menyampaikan pengalaman aplikasi yang terus-menerus meningkat sambil meminimalkan gangguan bagi pengguna Anda.

Teruskan dari Pengembalian

Jika Anda menggunakan Rollbacks untuk merencanakan rollback dan pengendalian versi, hubungkannya dengan Targeting Versi untuk detail implementasi di Targeting Versi, Pengaturan Perbarui untuk detail implementasi di Pengaturan Perbarui, bundel untuk detail implementasi di bundel, Capgo Live Updates untuk alur kerja produk di Capgo Live Updates, dan Strategi Rollback untuk Capacitor Update Langsung untuk konteks praktis dalam Strategi Rollback untuk Capacitor Update Langsung.