Perubahan yang Mengganggu

Dokumentasi ini menjelaskan cara mengatasi perubahan yang memecah dalam aplikasi Anda menggunakan saluran yang versi.

Dengan cara ini, Anda dapat mempertahankan versi aplikasi yang berbeda sambil memastikan pengguna menerima pembaruan yang kompatibel.

Judul bagian “Skenario Contoh”

• Versi Aplikasi 1.2.3 (versi lama) - menggunakan saluran produksi
• Versi Aplikasi 2.0.0 (versi baru dengan perubahan besar) - menggunakan saluran v2
• Pembaruan Langsung 1.2.4 (kompatibel dengan 1.2.3)
• Pembaruan Langsung 2.0.1 (kompatibel dengan 2.0.0)

Strategi: Selalu Gunakan defaultChannel untuk Versi Utama

Rekomendasi: Setel defaultChannel saluran untuk setiap versi utama. Dengan demikian, Anda dapat selalu memperbarui aplikasi untuk kelompok pengguna tertentu tanpa bergantung pada penugasan saluran dinamis.

// Version 1.x releases
defaultChannel: 'v1'

// Version 2.x releases
defaultChannel: 'v2'

// Version 3.x releases (future)
defaultChannel: 'v3'

Tips

Keuntungan dari pendekatan ini:

• Selalu memiliki kontrol atas pengguna mana yang menerima pembaruan
• Tidak perlu switching channel dinamis dalam aplikasi code
• Pemisahan yang jelas antara versi aplikasi yang berbeda
• Flexibilitas untuk memasukkan pembaruan ke versi grup tertentu

1. Buat Channel untuk Versi Baru

# Create channel for version 2.x
npx @capgo/cli channel create v2

2. Perbarui Capacitor Konfigurasi untuk Versi 2.0.0

Perbarui konfigurasi Capacitor Anda sebelum membangun versi 2.0.0 untuk toko aplikasi:

capacitor.config.ts

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example App',
  plugins: {
    CapacitorUpdater: {
      // ... other options
      defaultChannel: 'v2' // All 2.0.0 users will use v2 channel
    }
  }
};

export default config;

Catatan

Untuk versi 1.x: Jika Anda belum menetapkan defaultChannel awalnya, pengguna versi 1.x berada di production saluran. Untuk versi mayor masa depan, selalu tetapkan saluran spesifik seperti v3, v4dan lain-lain.

3. Kelola Cabang Terpisah Code

Buat cabang git terpisah untuk menjaga konsistensi antara versi aplikasi:

# Create and maintain a branch for version 1.x updates
git checkout -b v1-maintenance
git push origin v1-maintenance

# Your main branch continues with version 2.x development
git checkout main

Penting: Tidak pernah push bundle JavaScript ke aplikasi yang lebih tua yang mengharapkan native code/API yang tidak ada. Selalu bangun update dari cabang yang tepat:

• cabang pemeliharaan v1: Untuk update ke aplikasi 1.x (saluran produksi)
• cabang utama: Untuk update ke aplikasi 2.x (saluran v2)

4. Unggah Paket ke Saluran yang Sesuai

# For 1.x updates: Build from v1-maintenance branch
git checkout v1-maintenance
# Make your 1.x compatible changes here
npx @capgo/cli bundle upload --channel production

# For 2.x updates: Build from main branch
git checkout main
# Make your 2.x changes here
npx @capgo/cli bundle upload --channel v2

5. Aktifkan Penugasan Otomatis

# Allow apps to self-assign to v2 channel
npx @capgo/cli channel set v2 --self-assign

6. Rilis ke App Store

Catatan

Catatan

Tidak perlu ada perubahan code! Sejak defaultChannel: 'v2' tersedia dengan versi toko aplikasi, semua pengguna yang mengunduh versi 2.0.0 secara otomatis akan menggunakan saluran yang benar.

Mengukur untuk Versi Masa Depan

Ketika Anda merilis versi 3.0.0 dengan perubahan yang lebih berisiko:

# Create channel for version 3.x
npx @capgo/cli channel create v3

// capacitor.config.ts for version 3.0.0
const config: CapacitorConfig = {
  // ...
  plugins: {
    CapacitorUpdater: {
      defaultChannel: 'v3' // Version 3.x users
    }
  }
};

Sekarang Anda dapat memperbarui versi apa pun:

• production saluran → Pengguna versi 1.x
• v2 channel → Pengguna Versi 2.x
• v3 channel → Pengguna Versi 3.x

7. Pembersihan (Setelah Migrasi)

Setelah semua pengguna telah bermigrasi ke versi 2.x (hitung 3-4 bulan):

1. Hapus defaultChannel dari konfigurasi Capacitor Anda
2. Hapus saluran v2:

npx @capgo/cli channel delete v2

3. Hapus cabang v1-maintenance:

git branch -d v1-maintenance
git push origin --delete v1-maintenance

Tips

Dengan cara ini, pengguna hanya menerima pembaruan yang kompatibel dengan versi aplikasi mereka

Selalu tes pembaruan secara menyeluruh di setiap saluran sebelum di-deploy

Catatan

Anda dapat menghapus saluran v2 di Capgo dengan aman bahkan jika beberapa pengguna masih memiliki override saluran. Mereka akan secara otomatis menerima pembaruan dari saluran produksi.

Mengatur Pembaruan Versi 1.x

Untuk mengirimkan pembaruan yang kompatibel dengan versi 1.x:

1. Pindah ke cabang v1-maintenance:

git checkout v1-maintenance

2. Buat perubahan Anda dan komit:

# Make 1.x compatible changes
git add .
git commit -m "Fix for v1.x"
git push origin v1-maintenance

3. Buat dan unggah ke saluran produksi:

npx @capgo/cli bundle upload --channel production

Tip

Pastikan cabang v1-maintenance Anda selalu terkini dengan perbaikan bug yang kompatibel dengan versi 1.x, namun jangan pernah menggabungkan perubahan yang memecah dari main

Teruskan dari Perubahan yang Memecah

Jika Anda menggunakan Perubahan Pembaruan untuk merencanakan routing saluran dan peluncuran tahap demi tahap, hubungkannya dengan Saluran untuk detail implementasi di Saluran, Saluran untuk detail implementasi di Saluran, Saluran untuk detail implementasi di Saluran, Solusi Pengujian Beta untuk alur produk di Solusi Pengujian Beta, dan Solusi Target Versi untuk alur kerja produk di Solusi Target Versi.