Anda membuka proyek dan melihat build:ios:dev, build:android:qa, build:staging, build:release, build:prod, plus beberapa skrip shell yang tidak ingin disentuh. Lalu seseorang berkata, “Buatlah build staging untuk klien sebelum akhir hari.” Jika Anda seorang pengembang mobile menengah, permintaan tersebut seringkali terasa sangat kabur. Konfigurasi mana? Identitas signing mana? Backend mana? Jalur distribusi mana?
Ketidakjelasan biasanya berasal dari menganggap jenis build sebagai daftar yang rata. Mereka tidak. Mereka adalah alur kerja. Setiap build ada untuk menyelesaikan masalah tertentu pada titik tertentu antara laptop Anda dan perangkat pengguna.
Build bukan hanya aplikasi yang dikompilasi. Ini adalah versi aplikasi Anda yang disusun untuk tujuan, audiens, dan lingkungan tertentu. Beberapa build ada untuk membantu Anda debug. Beberapa ada untuk membantu QA memecahkan hal-hal dengan aman. Beberapa ada agar tim rilis dapat menghasilkan artefak yang dapat dipercaya. Beberapa ada agar tim produk dapat mengirimkan perubahan dengan risiko yang lebih rendah.
Jika setup lokal Anda masih terasa tidak stabil sebelum hal-hal tersebut dimulai, pastikan Anda mengaturnya terlebih dahulu dengan setup lingkungan lokal yang tepat Capacitor setup lingkungan lokal yang tepatDaftar Isi
Menemukan Dunia Build Perangkat Lunak
- Spektrum Build Lokal vs Build CI
- Build Lokal
- Build Debug
- Peta Build ke Lingkungan Distribusi
- Peran Kritis Code Signing
- Mengatur Rilis dengan CI/CD dan Saluran Perbarui
- Praktik Terbaik untuk Alur Kerja Pembangunan Modern
Menyederhanakan Dunia Pembangunan Perangkat Lunak
Kesalahan paling umum yang saya lihat adalah menganggap nama pembangunan memberitahu seluruh cerita. Mereka tidak. staging mungkin berarti “rasa rilis yang diarahkan ke API produksi.” Di repositori lain, mungkin berarti “artifact QA yang dapat di-debug dengan pembayaran yang dimock.” Di yang ketiga, mungkin berarti “pembangunan yang ditandatangani produksi yang didistribusikan secara pribadi.”
Itulah mengapa tim terjebak. Label hanya berguna jika Anda memahami pekerjaan yang dilakukan oleh pembangunan tersebut.
Cara berguna untuk berpikir tentang jenis-jenis pembangunan adalah ini:
- Pembangunan lokal membantu seorang pengembang individu bergerak cepat.
- Pembangunan CI membuat sumber kebenaran bersama untuk tim.
- Flavor debug dan rilis menentukan bagaimana aplikasi dikompilasi dan diinstrumentasi.
- Build distribusi menentukan siapa yang menerima aplikasi dan bagaimana.
- Build yang ditandatangani menentukan apakah platform akan mempercayai artefak.
- Pembaruan berdasarkan saluran menentukan bagaimana perubahan bergerak setelah instalasi.
Kategori-kategori tersebut tidak bersaing. Mereka bertumpuk.
Build 'staging' jarang merupakan satu hal. Biasanya kombinasi dari rasa, lingkungan, tanda tangan, dan pilihan distribusi.
Alasan itu dua tim dapat berbicara 'kami membutuhkan build beta' dan berarti artefak yang berbeda.
Hal ini paling penting pada perangkat seluler karena setiap langkah menambahkan gesekan. Pengompilan asli, rahasia, pengaturan, track aplikasi toko, akses tester, pengaturan lingkungan, dan rollback semua harus berbaris. Jika salah satu bagian longgar, proses rilis menjadi pengetahuan suku.
Tim yang mengelola ini dengan baik tidak mengingat lebih banyak skrip. Mereka mendefinisikan jenis bangunan sebagai pintu kualitas. Setiap pintu menurunkan jenis risiko yang berbeda: bangunan yang rusak code, konfigurasi yang salah, tanda tangan yang buruk, peluncuran yang buruk, atau pemulihan yang buruk.
Spektrum Bangunan vs Bangunan CI
Bangunan Lokal
Bangunan CI
Bangunan Lokal
Bangunan lokal adalah pribadi, cepat, dan dapat dibuang. Anda menggunakan mereka untuk menjawab pertanyaan langsung.
Apakah layar dapat menampilkan? Apakah plugin asli terinisialisasi? Apakah perubahan Gradle atau Xcode menghancurkan kompilasi? Apakah Anda dapat mereproduksi crash dengan logging yang ditingkatkan?
Bangunan lokal yang baik lebih memilih kecepatan daripada upacara. Mereka sering kali termasuk pengecekan yang lebih longgar, log yang lebih panjang, toggle pengembang, dan instrumen sementara. Itu tidak apa-apa. Tugasnya adalah memberikan feedback yang cepat.
Yang tidak berfungsi adalah mempromosikan bangunan lokal menjadi sesuatu yang lebih penting daripada itu. Bangunan lokal tidak boleh menjadi artefak rilis karena telah sukses dikompilasi di satu laptop.
Bangunan CI
Bangun CI lebih lambat karena alasan tertentu. Mereka menghilangkan keadaan mesin pribadi dari persamaan dan membuat proses bangun ulang dapat diulang kembali.
Mengapa CI sehat sangat penting:
- Bangun ulang dari awal: Membuktikan proyek dapat dikompilasi tanpa asumsi lokal yang disembunyikan.
- Jalankan periksaan tim-level: Uji unit, pemeriksaan lint, dan aturan pengemasan terjadi di tempat yang sama setiap kali.
- Menghasilkan artefak yang dapat dilihat: Tim dapat menghubungkan bangun ulang dengan komit, cabang, dan jalur pipeline.
Itulah mengapa saya menyukai analogi workshop-versus-factory. Laptop Anda adalah meja kerja tempat Anda melakukan iterasi. CI adalah garis produksi yang membuktikan proses itu nyata.
Jika tim Anda masih secara manual memutuskan skrip mana yang dijalankan di mana, sentralisasi logika itu dalam otomatisasi. Referensi yang praktis adalah panduan ini tentang mengelola bangun dev dan prod dengan __CAPGO_KEEP_0__ Actions managing dev and prod builds with GitHub Actions.
__CAPGO_KEEP_0__ Jika QA, produk, atau dukungan membutuhkan artefak, maka harus berasal dari CI, bukan dari mesin pengembang.
Setelah Anda menerima hal itu, maka sisa siklus pembangunan menjadi lebih mudah. Pemilihan rasa, penandatangan, penginjeksian lingkungan, dan distribusi semua termasuk dalam pipa yang dapat diperiksa oleh siapa saja di tim.
Core Build Flavors Debug vs Release
Ada banyak label yang digunakan untuk pembangunan, tetapi di bawah semua nama, dua rasa biasanya yang paling penting: debug dan release.
Mereka ada karena pengembang dan pengguna akhir membutuhkan hal yang berbeda.
Debug builds
Pembangunan debug bertujuan untuk membantu manusia memeriksa perilaku. Biasanya lebih banyak metadata yang disimpan, membuat troubleshooting lebih mudah, dan menghindari optimasi yang agresif yang dapat menyembunyikan masalah.
Ada analogi yang berguna dari spesifikasi konstruksi. Spesifikasi biasanya jatuh ke dalam Tipe Pembangunan, kinerja, milik sendiri, dan standar referensi tipe, dan sebuah pembangunan debug maps dengan rapi ke sebuah kinerja pendekatan karena itu menentukan alat-alat dan metode yang tepat untuk analisis, sementara sebuah pembangunan rilis maps ke sebuah kinerja pendekatan yang difokuskan pada hasil yang diperlukan, seperti yang dijelaskan dalam penjabaran ini dari spesifikasi konstruksi tipe pembangunan.
Dalam prakteknya, sebuah pembangunan debug adalah di mana Anda ingin hal-hal seperti:
- Diagnostik yang dapat dibaca: lacak stack, keluaran konsol, dan simbol yang membantu Anda menemukan kesalahan.
- Kemudahan pengembang: toggle palsu, menu uji, dan switch fitur yang tidak pantas bagi pengguna akhir.
- Iterasi dengan kecepatan rendah: siklus instalasi dan menjalankan yang lebih cepat lebih penting daripada paket yang terpolish.
Build debug bukanlah “buruk.” Mereka dibuat dengan tujuan tertentu.
Build rilis
Build rilis dibuat untuk perangkat di lapangan. Hal ini mengubah prioritas segera.
Sekarang Anda peduli dengan integritas paket, perilaku startup, postur keamanan yang lebih ketat, muatan yang lebih kecil, dan karakteristik waktu eksekusi yang dapat diprediksi. Anda juga ingin memiliki lebih sedikit titik masuk tidak sengaja untuk pemeriksaan atau penyalahgunaan.
Perubahan yang diharapkan adalah sederhana. Semua yang membuat build debug lebih mudah untuk diperiksa cenderung membuat build rilis kurang pantas untuk produksi.
Batasan keputusan yang saya gunakan bersama tim:
| Rasa | Terbaik untuk | Apa yang dioptimalkan |
|---|---|---|
| Debug | Pengembangan, pengujian lokal, reproduksi masalah | Kecepatan iterasi dan visibilitas |
| Release | Distribusi beta, pengiriman ke toko, peluncuran produksi | Stabilitas, kinerja, dan kepercayaan |
Mengapa tim masih melakukan kesalahan ini
Sebab utama kebingungan adalah mencampur "lingkungan" dengan "rasa."
Sebuah build dapat Rasa rilis yang ditujukan pada layanan pengujianYaitu umum untuk QA karena Anda ingin perilaku produksi dengan data non-produksi. Sebuah bangun juga dapat Rasa debug yang ditujukan pada layanan pengembangan
Untuk kegiatan coding sehari-hari. Mereka adalah bidang yang berbeda.
Sebagian besar penyebaran skrip berasal dari tim yang mengkodekan kombinasi yang mungkin dalam nama paket alih-alih mendokumentasikan matriks.
Kirim rasa rilis ketika non-pengembang melakukan pengujian perilaku pengguna. Simpan rasa debug untuk pekerjaan insinyur dan troubleshooting sengaja.
Aturan itu menghilangkan banyak kompleksitas yang tidak sengaja.
Peta Bangun ke Lingkungan Distribusi
Banyak diskusi tentang jenis bangun berhenti terlalu awal. Mereka menjelaskan lokal, debug, dan rilis, lalu mengabaikan pertanyaan yang lebih sulit: bangun ini pergi ke mana?
A practical build workflow usually moves through several environments, each with a different audience and tolerance for risk. If you’re working on Capacitor apps, it also helps to keep a clean mental separation between Sebuah alur kerja bangun yang praktis biasanya bergerak melalui beberapa lingkungan, masing-masing dengan audiens yang berbeda dan toleransi risiko yang berbeda. Jika Anda bekerja pada aplikasi Capacitor, juga membantu untuk menjaga pemisahan mental yang jelas antara perilaku aplikasi pengembangan dan produksi di CapacitorKarena banyak
masalah build
sebenarnya adalah kesalahan dalam peta lingkungan.
Nightly dan canary
Build ini adalah peringatan dini. Mereka untuk insinyur, QA, atau kelompok internal kecil yang bersedia menerima sudut kasar.
- Build nightly biasanya dibuat pada jadwal atau dari keadaan cabang utama terbaru. Build canary sengaja diberi kepada audiens yang terbatas sebelum peluncuran yang lebih luas. Saya menganggapnya sebagai alat belajar, bukan sebagai janji kestabilan.
- Mereka berguna ketika Anda perlu menjawab pertanyaan seperti:
- Apakah cabang terintegrasi dengan baik di antara modul?
Apakah pembaruan dependensi native memecahkan keluarga perangkat tertentu?
Apakah tester internal dapat menemukan regresi sebelum pengenalan beta yang lebih luas?
Apa yang tidak berfungsi adalah memberikan build canary kepada orang-orang yang mengharapkan perangkat lunak yang terpolish. Anda akan mendapatkan feedback yang berisik, dan audiens yang salah akan menganggap perubahan normal sebagai masalah peluncuran.
Staging dan beta
Penonton berubah di sini:
- Tim QA memvalidasi regresi, alur kerja, dan kriteria penerimaan.
- Pengelola produk memeriksa perilaku di shell yang realistis.
- Pengujian eksternal memvalidasi ketergunaan, penutupan perangkat, dan kasus tepi.
- Tim dukungan atau tim kesuksesan mungkin memperlihatkan perubahan yang akan datang.
Kesalahan di sini adalah menganggap beta sebagai “debug build lainnya.” Jika tester Anda menilai alur pengguna yang nyata, mereka membutuhkan kondisi rilis seperti itu.
Build distribusi pribadi
Beberapa aplikasi membutuhkan build yang tidak pernah sampai ke audiens toko publik sama sekali, atau perlu mencapai kelompok yang lebih sempit terlebih dahulu.
Termasuk build klien spesifik, aplikasi karyawan internal, alur kerja yang diatur, alat operasional lapangan, dan distribusi hanya untuk perusahaan. Mereka sering memerlukan kontrol yang lebih ketat atas siapa yang dapat menginstal aplikasi dan backend apa yang diakses.
Ini juga tempat di mana penamaan menjadi berbahaya. Tim sering mengatakan “build perusahaan” ketika mereka sebenarnya berarti salah satu hal yang berbeda:
- aplikasi internal yang ditandatangani secara pribadi
- aplikasi yang didistribusikan di toko dengan kontrol akses internal saja
- suatu artefak khusus pelanggan yang dibanderol
- kandidat rilis pra-produksi untuk tinjauan stakeholder
Itu adalah model operasional yang berbeda. Jaga mereka terpisah di pipa dan penamaan Anda.
Produksi
Rilis produksi adalah komitmen publik. Mereka pergi ke App Store, Play Store, atau saluran yang disetujui setara untuk pengguna Anda.
Pada titik ini, rilis haruslah membosankan. Itu adalah pujian.
Anda ingin rilis produksi dapat direproduksi, ditandatangani dengan benar, diuji dalam kondisi rilis, dan terkait dengan rencana rollback. Anda tidak ingin revisi manual terakhir, hack spesifik mesin, atau 'kita akan memperbaikinya di rilis berikutnya' kompromi.
Berikut versi ringkasan.
Jenis Rilis Perangkat Lunak dan Karakteristiknya
| Jenis Rilis | Audien | Konfigurasi | Metode Distribusi |
|---|---|---|---|
| Pengembang lokal | Pengembang individu | Biasanya debug, iterasi cepat, pengaturan lingkungan lokal | Instal langsung dari mesin lokal |
| Validasi CI | Tim ahli teknik | Bangunan otomatis ulang, periksa bersama | Penyimpanan artefak CI |
| Malam hari atau canary | Tes internal, anggota tim yang dipilih | Status integrasi awal, rollout terbatas | Alat distribusi internal |
| Staging atau beta | QA, produk, pengujian internal | Biasanya lingkungan mapping non publik, mirip dengan produksi | Pengujian TestFlight, track Play, tautan pribadi |
| Ad-hoc atau perusahaan | Karyawan internal, klien, kelompok terbatas | Konfigurasi terkendali, tanda tangan spesifik tujuan | Saluran distribusi pribadi |
| Produksi | Pengguna publik | Konfigurasi rilis akhir, tanda tangan siap toko | App Store atau Google Play |
Jenis build yang tepat adalah yang sesuai dengan toleransi risiko audiens. Kesalahan rilis paling banyak terjadi ketika tim melewatkan alihan tersebut.
Peran Kritis Code Signing
File build sendiri tidak berarti banyak di mobile. Platform membutuhkan bukti bahwa itu berasal dari sumber yang dipercaya dan tidak ada yang mengubahnya setelah pembuatan. Bukti itu adalah __CAPGO_KEEP_0__ signing code signing.
Sebuah layar komputer menampilkan kode sumber Python untuk Blender dengan teks overlay Signing __CAPGO_KEEP_1__
Untuk tim mobile, __CAPGO_KEEP_0__ signing melakukan tiga hal.
For a mobile team, code signing does three jobs.
- mengikat aplikasi ke pengembang atau organisasi yang menghasilkannya. Integritas:
- mengamankan bahwa aplikasi tidak telah diubah setelah pembuatan. membantu membuktikan bahwa artefak tersebut tidak telah dimanipulasi sejak ditandatangani.
- Otorisasi: terutama di platform Apple, itu juga mengontrol di mana dan bagaimana aplikasi diizinkan untuk berjalan.
Titik ketiga itu yang membingungkan banyak pengembang. Tanda tangan bukan hanya identitas. Tanda tangan juga adalah izin.
Jadi aplikasi yang sama code dapat memerlukan bahan tanda tangan yang berbeda tergantung apakah Anda ingin menjalankannya secara lokal di perangkat, mengirimkannya ke tester, mengirimkannya secara internal, atau mengirimkannya ke toko.
Bagaimana tanda tangan berubah tergantung pada tujuan
Ini adalah model mental yang menjaga proses tetap seimbang: tanda tangan mengikuti distribusi.
Pemasangan pengembang lokal menggunakan satu set identitas dan izin. Rilis beta yang dikirim melalui TestFlight menggunakan set lain. Jalur distribusi internal mungkin memerlukan profil yang berbeda lagi. Rilis publik di toko memiliki harapan tanda tangan dan pengemasan yang dapat disetujui oleh pengulas.
Itulah mengapa
hanya tanda tangan ulang
- jarang merupakan permintaan kecil. Saat tanda tangan berubah, tujuan yang diizinkan artefak dapat berubah bersamanya. bukan di laptop pribadi.
- Penyebutan jelas berdasarkan target: pengembangan, pengujian pribadi, bisnis, rilis toko.
- Pengaturan rotasi dan kontrol akses: terutama ketika kontraktor atau tim produk berbagi infrastruktur.
- Keterbukaan audit: anda perlu tahu mana pipeline yang menggunakan identitas tanda tangan mana.
Jika tim Anda mengirimkan pembaruan web di dalam aplikasi Capacitor, ada lapisan tanda tangan kedua untuk dipertimbangkan juga. Ringkasan ini tentang Capacitor updater __CAPGO_KEEP_1__ tanda tangan akhir-ke-akhirinya end-to-end security for Capacitor updater code signing Masalah tanda tangan biasanya tidak berasal dari kriptografi. Masalahnya berasal dari kepemilikan yang tidak jelas, penanganan manual, dan alur bangun yang menyembunyikan identitas mana yang digunakan.
Tangani bahan tanda tangan seperti infrastruktur produksi, karena itu apa yang dia adalah.
Pengaturan rotasi dan kontrol akses: terutama ketika kontraktor atau tim produk berbagi infrastruktur.
Merayakan Rilis dengan CI/CD dan Saluran Perbarui
Dengan waktu yang tepat, tim yang matang bukanlah tantangan mengetahui jenis-jenis bangun. Tapi itu mengkoordinasikannya tanpa perlu menebak secara manusia.
Koordinasi itu harus ada di CI/CD.
Aliran pipa Anda adalah kontrak bangun
Aliran pipa yang dapat diandalkan harus menjawab pertanyaan-pertanyaan yang sama setiap kali:
- apa tujuan bangun ini
- apa rasa yang digunakan
- nilai-nilai lingkungan apa yang diterima
- tes apa yang harus dilewati
- identitas tanda tangan apa yang berlaku
- di mana hasil artefaknya dikirimkan
Struktur itu menggambarkan spesifikasi teknis yang baik. Spesifikasi yang baik harus mencakup tujuan dan ruang lingkup, persyaratan fungsional, persyaratan desain, standar teknis, persyaratan pengujian, persyaratan pengiriman, dan persyaratan dukungan atau perawatan, seperti yang dijelaskan dalam pedoman spesifikasi teknis ini. Disiplin yang sama membuat CI/CD lebih mudah dipahami karena pipeline tidak lagi menjadi kumpulan skrip dan menjadi kebijakan peluncuran yang dapat dieksekusi.
Ini berlaku dalam prakteknya, pipeline harus dapat memutuskan, bukan insinyur yang menjalankannya secara manual. Aturan cabang, tag, langkah persetujuan, konteks tanda tangan, dan target pengiriman harus semua direkod.
Yang berhasil:
- Intensi cabang yang dipimpin: cabang utama, cabang rilis, dan tag memicu alur kerja yang berbeda.
- Pemberian nama artefak yang eksplisit: rasa, lingkungan, dan target dapat dilihat dalam hasil.
- Promosi bukanlah merekonstruksi secara manual: menggerakkan artefak yang telah diverifikasi ke depan daripada menciptakan mereka secara ad hoc.
Apa yang gagal secara konsisten adalah pendekatan skrip yang fleksibel, di mana semua orang melewati flag yang disesuaikan dan berharap mereka sesuai dengan apa yang dibutuhkan toko atau tester.
Saluran menambahkan kontrol setelah binary berlayar.
Pembangunan asli masih kasar. Setelah rilis masuk ke toko, mengubah konten web di dalam aplikasi Capacitor tidak selalu memerlukan binary yang baru secara keseluruhan.
Itu di mana saluran pembaruan menjadi berguna. Mereka memungkinkan tim untuk mengarahkan pembaruan aset web ke subset pengguna di dalam binary produksi yang terpasang. Untuk tim Capacitor, salah satu pilihan adalah Capgoyang menerbitkan bundle web yang ditandatangani ke saluran yang ditargetkan sehingga Anda dapat mendorong perubahan JavaScript, CSS, salinan, konfigurasi, dan aset tanpa membangun shell native setiap kali.
Polanya yang praktis seperti ini:
- Pembangunan binary di CI/CD: buat, tandatangani, dan distribusikan aplikasi native.
- Pengaturan saluran: mapkan pengguna atau lingkungan ke saluran beta, pengembangan, produksi, atau aliran khusus pelanggan.
- Rollout selektif: Pengiriman perubahan web ke satu kelompok sebelum pengecualian yang lebih luas.
- Jalur rollback: Mengaktifkan atau mengembalikan pembaruan yang buruk tanpa menunggu tinjauan toko.
Jika Anda belum mengatur model tersebut, panduan ini pada membuat dan menghapus saluran pembaruan di Capacitor menjelaskan prinsip-prinsipnya secara lebih konkrit.
Demo singkat membantu jika Anda belum melihat saluran dalam aksi:
Pergeseran strategis yang dibutuhkan oleh banyak tim mobile. Tipe-tipe build bukan hanya artefak. Mereka adalah titik kontrol. CI/CD mengontrol bagaimana biner diproduksi. Saluran mengontrol bagaimana perubahan pasca-instalasi diekspos.
Praktik Terbaik untuk Arus Kerja Build Modern
Sistem build yang seimbang adalah opini. Dia tidak membiarkan setiap pengembang mengimprovisasi perilaku rilis.
Setelan yang kuat yang pernah saya kerjakan bersama memiliki beberapa kebiasaan:
- Jelaskan sumbu secara jelas: Pilih rasa, lingkungan, target tanda tangan, dan target distribusi tidak boleh dicampur menjadi satu label yang kabur.
- Biarkan CI menghasilkan artefak yang berhadapan dengan tim: Pembangunan lokal adalah untuk pengembangan, bukan untuk kepercayaan pihak terkait.
- Uji coba dalam kondisi rilis awal: QA dan tester beta harus melihat perilaku yang sesuai dengan aplikasi asli sejauh mungkin.
- Simpan aset tanda tangan di luar laptop: Rahasia harus berada di infrastruktur yang dikendalikan dengan akses yang sempit.
- Berikan nama artefak sehingga manusia dapat membacanya: Jika seseorang tidak dapat mengidentifikasi apa itu file untuk dalam beberapa detik, penamaan itu buruk.
- Lebih baik promosikan daripada mereproduksi: Saat artefak telah diverifikasi, pindahkan ke depan melalui alur kerja daripada membangun secara manual.
- Perencanaan ulang sebelum peluncuran: Ulang balik toko adalah lambat dan berat operasional. Ulang balik layer web untuk pembaruan Capacitor dapat lebih cepat, tetapi hanya jika Anda merencanakan saluran dan kebijakan terlebih dahulu.
Pemikiran besar perubahan adalah ini: jangan bertanya 'skrip bangun mana yang harus saya jalankan?' Tanya 'apa risiko yang saya kelola pada tahap ini?' Pertanyaan itu menghasilkan sistem bangun yang lebih baik.
Jika alur kerja Anda menjawab hal itu dengan jelas, proses rilis Anda menjadi lebih mudah dioperasikan, lebih mudah diverifikasi, dan jauh lebih tidak bergantung pada satu insinyur senior yang mengingat incantasi yang tepat.
Jika tim Anda mengirimkan aplikasi Capacitor dan ingin memiliki kontrol yang lebih ketat atas alur kerja rilis, Capgo bernilai untuk dievaluasi sebagai bagian dari stack tersebut. Ini menghandle pembaruan hidup yang sasaran untuk asset web di dalam aplikasi Capacitor , mendukung bundle yang ditandatangani, peluncuran berdasarkan saluran, dan kontrol ulang balik, yang membuatnya berguna ketika Anda membutuhkan perbaikan yang lebih cepat tanpa menggantikan pipa bangun asli.
