Bagikan melalui

Penyebaran

  • Artikel

Penting

Visual Studio App Center dijadwalkan untuk dihentikan pada 31 Maret 2025. Meskipun Anda dapat terus menggunakan Visual Studio App Center hingga sepenuhnya dihentikan, ada beberapa alternatif yang direkomendasikan yang dapat Anda pertimbangkan untuk bermigrasi.

Pelajari selengkapnya tentang garis waktu dukungan dan alternatif.

Pengujian Multi-Penyebaran

Dalam dokumen memulai kami, kami mengilustrasikan cara mengonfigurasi plugin CodePush menggunakan kunci penyebaran tertentu. Namun, untuk menguji rilis Anda secara efektif, sangat penting bagi Anda untuk menggunakan Staging penyebaran dan Production yang kami sarankan untuk dibuat saat pertama kali membuat aplikasi CodePush (atau penyebaran kustom apa pun yang mungkin telah Anda buat). Dengan cara ini, Anda tidak pernah merilis pembaruan untuk pengguna akhir yang belum dapat Anda validasi sendiri.

Catatan

Fitur putar kembali sisi klien kami dapat membantu membuka blokir pengguna setelah menginstal rilis yang mengakibatkan crash, dan rollback sisi server (yaitu appcenter codepush rollback) memungkinkan Anda untuk mencegah pengguna tambahan menginstal rilis yang buruk setelah diidentifikasi. Namun, lebih baik jika Anda dapat mencegah pembaruan yang salah dirilis secara luas di tempat pertama.

Staging Memanfaatkan penyebaran dan Production memungkinkan Anda mencapai alur kerja seperti berikut ini (jangan ragu untuk menyesuaikan!):

  1. Merilis pembaruan CodePush ke penyebaran Anda Staging menggunakan appcenter codepush release-react perintah (atau appcenter codepush release jika Anda memerlukan lebih banyak kontrol)

  2. Jalankan build penahapan/beta aplikasi Anda, sinkronkan pembaruan dari server, dan verifikasi bahwa aplikasi berfungsi seperti yang diharapkan

  3. Mempromosikan rilis yang diuji dari Staging ke Production menggunakan appcenter codepush promote perintah

  4. Jalankan build produksi/rilis aplikasi Anda, sinkronkan pembaruan dari server dan verifikasi bahwa aplikasi berfungsi seperti yang diharapkan

    Tip

    Jika Anda ingin mengambil pendekatan yang lebih hati-hati, Anda bahkan dapat memilih untuk melakukan "peluncuran bertahap" sebagai bagian dari #3, yang memungkinkan Anda untuk mengurangi potensi risiko tambahan dengan pembaruan (seperti pengujian Anda di #2 menyentuh semua perangkat/kondisi yang mungkin?) dengan hanya membuat pembaruan produksi tersedia untuk persentase pengguna Anda (misalnya appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20). Kemudian, setelah menunggu waktu yang wajar untuk melihat apakah ada laporan crash atau umpan balik pelanggan masuk, Anda dapat memperluasnya ke seluruh audiens Anda dengan menjalankan appcenter codepush patch -a <ownerName>/<appName> Production -r 100.

Langkah-langkah di atas mengacu pada "build penahapan" dan "build produksi" aplikasi Anda. Jika proses build Anda sudah menghasilkan biner yang berbeda per "lingkungan", maka Anda tidak perlu membaca lebih lanjut, karena menukar kunci penyebaran CodePush seperti menangani konfigurasi khusus lingkungan untuk layanan lain yang digunakan aplikasi Anda (seperti Facebook). Namun, jika Anda mencari contoh tentang cara menyiapkan proses build untuk mengakomodasinya, lihat bagian berikut, bergantung pada platform yang ditargetkan aplikasi Anda.

Android

Plugin Android Gradle memungkinkan Anda menentukan pengaturan konfigurasi kustom untuk setiap "jenis build" (seperti debug, rilis). Mekanisme ini memungkinkan Anda untuk dengan mudah mengonfigurasi build debug Anda untuk menggunakan kunci penyebaran penahapan CodePush dan build rilis Anda untuk menggunakan kunci penyebaran produksi CodePush Anda.

Catatan

Sebagai pengingat, Anda dapat mengambil kunci ini dengan menjalankan appcenter codepush deployment list -a <ownerName>/<appName> -k dari terminal Anda.

Untuk menyiapkan ini, ikuti langkah-langkah berikut:

Untuk React Native >= v0.60

  1. Buka file tingkat build.gradle aplikasi proyek (misalnya android/app/build.gradle dalam proyek React Native standar)

  2. Temukan bagian android { buildTypes {} } dan tentukan resValue entri untuk jenis build dan release Andadebug, yang masing-masing mereferensikan kunci penyebaran dan Production AndaStaging.

    android {
    ...
    buildTypes {
        debug {
            ...
            // Note: CodePush updates shouldn't be tested in Debug mode as they're overriden by the RN packager. However, because CodePush checks for updates in all modes, we must supply a key.
            resValue "string", "CodePushDeploymentKey", '""'
            ...
        }
        releaseStaging {
            ...
            resValue "string", "CodePushDeploymentKey", '"<INSERT_STAGING_KEY>"'
            // Note: It's a good idea to provide matchingFallbacks for the new buildType you create to prevent build issues
            // Add the following line if not already there
            matchingFallbacks = ['release']
            ...
        }
        release {
            ...
            resValue "string", "CodePushDeploymentKey", '"<INSERT_PRODUCTION_KEY>"'
            ...
        }
    }
    ...
}

Catatan

Ingatlah untuk menghapus kunci dari strings.xml jika Anda mengonfigurasi kunci penyebaran dalam proses build*

Catatan

Konvensi penamaan untuk releaseStaging signifikan karena baris ini.

Untuk React Native v0.29 - v0.59

  1. Buka file Anda MainApplication.java dan buat perubahan berikut:

    @Override
protected List<ReactPackage> getPackages() {
     return Arrays.<ReactPackage>asList(
         ...
         new CodePush(BuildConfig.CODEPUSH_KEY, MainApplication.this, BuildConfig.DEBUG), // Add/change this line.
         ...
     );
}

  2. Buka file aplikasi build.gradle Anda (misalnya android/app/build.gradle dalam proyek React Native standar)

  3. Temukan bagian android { buildTypes {} } dan tentukan buildConfigField entri untuk jenis build dan release Andadebug, yang masing-masing mereferensikan kunci penyebaran dan Production AndaStaging. Jika mau, Anda dapat menentukan literal kunci dalam file Anda gradle.properties , lalu mereferensikannya di sini. Cara apa pun akan bekerja, dan itu adalah masalah preferensi pribadi.

    android {
    ...
    buildTypes {
        debug {
            ...
            // Note: CodePush updates shouldn't be tested in Debug mode as they're overridden by the RN packager. However, because CodePush checks for updates in all modes, we must supply a key.
            buildConfigField "String", "CODEPUSH_KEY", '""'
            ...
        }

        releaseStaging {
            ...
            buildConfigField "String", "CODEPUSH_KEY", '"<INSERT_STAGING_KEY>"'

            // Note: It's a good idea to provide matchingFallbacks for the new buildType you create to prevent build issues
            // Add the following line if not already there
            matchingFallbacks = ['release']
            ...
        }

        release {
            ...
            buildConfigField "String", "CODEPUSH_KEY", '"<INSERT_PRODUCTION_KEY>"'
            ...
        }
    }
    ...
}

    Tip

    Sebagai pengingat, Anda dapat mengambil kunci ini dengan menjalankan appcenter codepush deployment list -a <ownerName>/<appName> --displayKeys dari terminal Anda.

    Catatan

    Konvensi penamaan untuk releaseStaging signifikan karena baris ini.

  4. Teruskan kunci penyebaran ke CodePush konstruktor melalui konfigurasi build yang Anda tentukan, dibandingkan dengan string literal.

Untuk React Native v0.19 - v0.28

Buka file MainActivity.java Anda dan buat perubahan berikut:

@Override
protected List<ReactPackage> getPackages() {
    return Arrays.<ReactPackage>asList(
        ...
        new CodePush(BuildConfig.CODEPUSH_KEY, this, BuildConfig.DEBUG), // Add/change this line.
        ...
    );
}

Catatan

Jika Anda memberi pengaturan build nama yang berbeda di file Gradle, pastikan untuk mencerminkannya dalam kode Java Anda.

Dan itu saja! Sekarang saat Anda menjalankan atau membangun aplikasi, build debug Anda akan secara otomatis dikonfigurasi untuk disinkronkan dengan penyebaran Anda Staging , dan build rilis Anda akan dikonfigurasi untuk disinkronkan dengan penyebaran Anda Production .

Catatan

Secara default, react-native run-android perintah membuat dan menyebarkan versi debug aplikasi Anda, jadi jika Anda ingin menguji build rilis/produksi, jalankan rilis 'react-native run-android --variant. Lihat dokumen React Native untuk detail tentang cara mengonfigurasi dan membuat build rilis untuk aplikasi Android Anda.

Jika Anda ingin menginstal build debug dan rilis secara bersamaan pada perangkat yang sama (sangat disarankan!), maka Anda perlu memastikan bahwa build debug Anda memiliki identitas dan ikon unik dari build rilis Anda. Jika tidak, OS, atau Anda, tidak dapat membedakan antara keduanya. Anda dapat mengonfigurasi identitas unik dengan melakukan langkah-langkah berikut:

  1. Dalam file build.gradle Anda, tentukan applicationIdSuffix bidang untuk jenis build debug Anda, yang memberi build debug Anda identitas unik untuk OS (seperti com.foo vs. com.foo.debug).

    buildTypes {
    debug {
        applicationIdSuffix ".debug"
    }
}

  2. app/src/debug/res Buat struktur direktori di aplikasi Anda, yang memungkinkan penggantian sumber daya (seperti string, ikon, tata letak) untuk build debug Anda

  3. Buat values direktori di bawah direktori debug res yang dibuat di #2, dan salin file yang ada strings.xml dari app/src/main/res/values direktori

  4. Buka file debug strings.xml baru dan ubah <string name="app_name"> nilai elemen menjadi sesuatu yang lain (seperti foo-debug). Ini memastikan bahwa build debug Anda sekarang memiliki nama tampilan yang berbeda, sehingga Anda dapat membedakannya dari build rilis Anda.

  5. Secara opsional, buat direktori "cermin" di app/src/debug/res direktori untuk semua ikon aplikasi yang ingin Anda ubah untuk build debug Anda. Bagian ini tidak terlalu penting secara teknis, tetapi dapat mempermudah untuk dengan cepat melihat build debug Anda pada perangkat jika ikonnya terlihat berbeda.

Dan itu saja! Lihat penggabungan sumber daya untuk informasi selengkapnya tentang cara kerja penggabungan sumber daya di Android.

iOS

Xcode memungkinkan Anda menentukan pengaturan build kustom untuk setiap "konfigurasi" (seperti debug, rilis), yang dapat dirujuk sebagai nilai kunci dalam file Info.plist (seperti CodePushDeploymentKey pengaturan). Mekanisme ini memungkinkan Anda untuk dengan mudah mengonfigurasi build Anda untuk menghasilkan biner, yang dikonfigurasi untuk disinkronkan dengan penyebaran CodePush yang berbeda.

Untuk menyiapkan ini, ikuti langkah-langkah berikut:

  1. Buka proyek Xcode Anda dan pilih proyek Anda di jendela Navigator proyek

  2. Pastikan simpul proyek dipilih, dibandingkan dengan salah satu target Anda

  3. Pilih tab Info

  4. Klik tombol di + dalam bagian Konfigurasi dan pilih Konfigurasi Duplikat "Rilis"

    Konfigurasi

  5. Beri nama Penahapan konfigurasi baru (atau apa pun yang Anda inginkan)

  6. Pilih tab Pengaturan Build

  7. Klik tombol + pada toolbar dan pilih Tambahkan Pengaturan User-Defined

    Pengaturan

    Beri nama pengaturan ini MULTI_DEPLOYMENT_CONFIG. Buka pengaturan dan tambahkan nilai $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) untuk Rilis. Setelah itu tambahkan nilai $(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME) untuk Penahapan.

    MultiDeploymentConfig

    Catatan

    Untuk Xcode 10 dan versi yang lebih rendah: Buka Lokasi > Build Per konfigurasi Bangun Penahapan Jalur > Produk dan ubah nilai Penahapan dari $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) ke $(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)

    BuildFilesPath

    Catatan

    https://github.com/facebook/react-native/issues/11813Karena itu, kita harus melakukan langkah ini untuk memungkinkan penggunaan konfigurasi lain daripada Debug atau Rilis pada RN 0.40.0 atau yang lebih tinggi.

  8. Klik tombol + lagi pada toolbar dan pilih Tambahkan Pengaturan User-Defined

    Beri nama pengaturan CODEPUSH_KEYini , perluas, dan tentukan kunci penyebaran Penahapan Anda untuk konfigurasi Penahapan dan kunci penyebaran Produksi Anda untuk konfigurasi Rilis .

    Mengatur Kunci

    Catatan

    Sebagai pengingat, Anda dapat mengambil kunci ini dengan menjalankan appcenter codepush deployment list -a <ownerName>/<appName> --displayKeys dari terminal Anda.

  9. Buka file Info.plist proyek dan ubah nilai entri Anda CodePushDeploymentKey menjadi $(CODEPUSH_KEY)

    Info.plist

Dan itu saja! Sekarang saat Anda menjalankan atau membangun aplikasi, build penahapan Anda akan secara otomatis dikonfigurasi untuk disinkronkan dengan penyebaran Penahapan , dan build rilis Anda akan dikonfigurasi untuk disinkronkan dengan penyebaran Produksi Anda.

Catatan

Jika Anda menemukan pesan ld: library not found for ...kesalahan , periksa masalah ini untuk kemungkinan solusi.

Selain itu, jika Anda ingin memberi mereka nama atau ikon terpisah, Anda dapat memodifikasi Product Bundle Identifierpengaturan build , , Product Namedan Asset Catalog App Icon Set Name , yang memungkinkan build penahapan Anda dapat dibedakan dari build rilis saat diinstal pada perangkat yang sama.

Penetapan Penyebaran Dinamis

Bagian di atas menggambarkan bagaimana Anda dapat menggunakan beberapa penyebaran CodePush untuk menguji pembaruan Anda secara efektif sebelum merilisnya secara luas kepada pengguna akhir Anda. Namun, karena alur kerja tersebut secara statis menyematkan penetapan penyebaran ke dalam biner aktual, penahapan atau build produksi hanya akan menyinkronkan pembaruan dari penyebaran tersebut. Dalam banyak kasus, ini cukup, karena Anda hanya ingin tim, pelanggan, pemangku kepentingan, dll Anda disinkronkan dengan rilis pra-produksi Anda, dan karenanya, mereka hanya memerlukan build yang tahu cara menyinkronkan dengan penahapan. Namun, jika Anda ingin melakukan pengujian A/B, atau menyediakan akses awal aplikasi Anda kepada pengguna tertentu, itu dapat terbukti berguna untuk secara dinamis menempatkan pengguna tertentu (atau audiens) ke dalam penyebaran tertentu pada waktu proses.

Untuk mencapai alur kerja ini, tentukan kunci penyebaran yang Anda inginkan untuk disinkronkan dengan pengguna saat ini saat memanggil codePush metode . Jika ditentukan, kunci ini akan menggantikan file "default" yang disediakan di file Info.plist (iOS) atau MainActivity.java (Android) aplikasi Anda. Ini memungkinkan Anda untuk menghasilkan build untuk penahapan atau produksi, yang juga mampu "dialihkan" secara dinamis sesuai kebutuhan.

// Imagine that "userProfile" is a prop that this component received
// that includes the deployment key that the current user should use.
codePush.sync({ deploymentKey: userProfile.CODEPUSH_KEY });

Dengan perubahan tersebut, sekarang masalahnya adalah memilih bagaimana aplikasi Anda menentukan kunci penyebaran yang tepat untuk pengguna saat ini. Dalam praktiknya, biasanya ada dua solusi untuk ini:

  1. Mengekspos mekanisme yang terlihat pengguna untuk mengubah penyebaran kapan saja. Misalnya, halaman pengaturan Anda dapat beralih untuk mengaktifkan akses "beta". Model ini berfungsi dengan baik jika Anda tidak peduli dengan privasi pembaruan pra-produksi Anda, dan Anda memiliki pengguna daya yang mungkin ingin ikut serta dalam pembaruan sebelumnya (dan berpotensi buggy) sesuai keinginan mereka sendiri (seperti saluran Chrome). Namun, solusi ini menempatkan keputusan di tangan pengguna Anda, yang tidak membantu Anda menjalankan pengujian A/B secara transparan.

  2. Buat anotasi profil sisi server pengguna Anda dengan bagian metadata tambahan yang menunjukkan penyebaran yang harus mereka sinkronkan. Secara default, aplikasi Anda dapat menggunakan kunci yang disematkan biner, tetapi setelah pengguna mengautentikasi, server Anda dapat memilih untuk "mengalihkannya" ke penyebaran yang berbeda, yang memungkinkan Anda menempatkan pengguna atau grup tertentu secara bertahap dalam penyebaran yang berbeda sesuai kebutuhan. Anda bahkan dapat memilih untuk menyimpan respons server di penyimpanan lokal sehingga menjadi default baru. Cara Anda menyimpan kunci bersama profil pengguna sepenuhnya sesuai dengan solusi autentikasi Anda (misalnya Auth0, Firebase, DB + REST API kustom), tetapi umumnya cukup sepele untuk dilakukan.

    Catatan

    Jika diperlukan, Anda juga dapat menerapkan solusi hibrid yang memungkinkan pengguna akhir Anda beralih di antara penyebaran yang berbeda, sekaligus memungkinkan server Anda untuk mengambil alih keputusan tersebut. Dengan cara ini, Anda memiliki hierarki "resolusi penyebaran" yang memastikan aplikasi Anda memiliki kemampuan untuk memperbarui dirinya sendiri secara langsung, pengguna akhir Anda dapat merasa dihargai dengan mendapatkan akses awal ke bit, tetapi Anda juga memiliki kemampuan untuk menjalankan pengujian A/B pada pengguna Anda sesuai kebutuhan.

Karena sebaiknya gunakan Staging penyebaran untuk pengujian pra-rilis pembaruan Anda (seperti yang dijelaskan di bagian sebelumnya), tidak selalu masuk akal untuk menggunakannya untuk pengujian A/B pada pengguna Anda, dibandingkan dengan mengizinkan akses awal (seperti yang dijelaskan dalam opsi #1 di atas). Jadi, sebaiknya gunakan sepenuhnya penyebaran aplikasi kustom, sehingga Anda dapat membagmentasikan pengguna Anda namun masuk akal untuk kebutuhan Anda. Misalnya, Anda dapat membuat penyebaran jangka panjang atau bahkan satu kali, merilis varian aplikasi Anda ke dalamnya, lalu menempatkan pengguna tertentu ke dalamnya untuk melihat bagaimana mereka terlibat.

// #1) Create your new deployment to hold releases of a specific app variant
appcenter codepush deployment add -a <ownerName>/<appName> test-variant-one

// #2) Target any new releases at that custom deployment
appcenter codepush release-react -a <ownerName>/<appName> -d test-variant-one

Catatan

Karakter "/" dan ":" tidak didukung dalam nama penyebaran.

Catatan

Jumlah total pengguna yang dilaporkan dalam "Pasang Metrik" penyebaran Anda akan memperhitungkan pengguna yang telah "beralih" dari satu penyebaran ke penyebaran lainnya. Misalnya, jika penyebaran Produksi Anda saat ini melaporkan memiliki 1 total pengguna, tetapi Anda secara dinamis mengalihkan pengguna tersebut ke Penahapan, maka penyebaran Produksi akan melaporkan 0 total pengguna, sementara Penahapan akan melaporkan 1 (pengguna yang beralih). Perilaku ini memungkinkan Anda untuk melacak adopsi rilis Anda secara akurat, bahkan jika menggunakan solusi pengalihan penyebaran berbasis runtime.