Pada pukul 16:47 pada hari Jumat, seorang pengembang menerapkan perbaikan CSS satu baris. Perubahan tampaknya tidak berbahaya, tetapi penanda pipa merah mengatakan lain. Tim dapat memilih untuk menghabiskan sore hari menelusuri build mobile yang rusak atau bergantung pada otomatisasi yang mengidentifikasi kegagalan saat perubahan masih segar.
Itu adalah janji praktis dari Integrasi Terus Menerus/CD. Pengembang menyatukan perubahan kecil secara sering, sebuah pipeline otomatis membangun dan menguji setiap perubahan, dan sebuah artefak yang diverifikasi bergerak menuju pengguna tanpa bergantung pada keberanian manual. Dalam sebuah aplikasi CapacitorJS, model yang sama harus mempertimbangkan JavaScript, proyek native iOS dan Android, kunci tanda tangan, alur toko, dan perilaku perangkat.
Daftar Isi
- Arti Nyata Integrasi Terus Menerus/CD
- 5 Blok Bangunan Setiap Pipeline Integrasi Terus Menerus/CD
- Penyampaian Terus Menerus vs Penyebaran Terus Menerus
- Pipeline Integrasi Terus Menerus/CD Nyata untuk Aplikasi Mobile CapacitorJS
- Tambahkan Live Updates ke Alur CI/CD Anda dengan Capgo
- Keamanan dan AI di Pipa CI/CD Hari Ini
- Daftar Periksa Kematangan untuk Pengaturan CI/CD Anda
Apakah CI/CD Integrasi Terus Menerus Sebenarnya Berarti dalam Praktik
Integrasi Terus-Menerus berarti pengembang secara teratur menggabungkan pekerjaan mereka di repositori Git bersama. Setiap push atau permintaan pull memulai validasi otomatis, biasanya termasuk instalasi dependensi, pembersihan kode, pengujian unit, dan pembangunan. Tujuan bukanlah untuk membuktikan bahwa aplikasi tidak memiliki bug. Itu adalah untuk menemukan asumsi yang rusak saat perubahan relevan masih mudah dipahami.
Untuk proyek CapacitorJS, validasi tersebut mungkin dimulai dengan npm ci, diikuti oleh pengujian web dan pembangunan produksi. Pipa dapat menjalankan npx cap sync untuk menyalin aset web dan perubahan plugin native ke proyek iOS dan Android. Hasil hijau berarti repositori menghasilkan kandidat yang kohesif, bukan sekadar bahwa laptop pengembang satu orang berhasil.
Pengiriman Terus-Menerus mengembangkan proses di luar validasi. Pipa menghasilkan artefak yang versi dan menjaganya siap untuk dilepaskan ke tahap pengujian atau produksi. Seorang manusia masih dapat menyetujui rilis akhir, terutama ketika tim memerlukan tinjauan komplian, koordinasi toko, atau jendela peluncuran yang dikendalikan.
Pengiriman Terus-Menerus menghilangkan langkah persetujuan tersebut. Setiap perubahan yang lolos pengecekan yang ditentukan dapat dilepaskan secara otomatis. Model tersebut hanya berfungsi ketika pengujian, kredential, kontrol peluncuran, pemantauan, dan prosedur rollback dapat menyerap kesalahan.
Mobile development membuat masalah pengiriman yang sama menjadi lebih rumit. Deploy web memiliki satu target runtime, sementara aplikasi Capacitor mungkin memerlukan arsip iOS, aplikasi Android Bundle, sertifikat, profil pengaturan, metadata toko, dan pengecekan kompatibilitas di perangkat fisik. Capgo’s panduan tentang manfaat kontinu integrasi.
Aturan praktis: CI harus membuat perubahan buruk terlihat dengan cepat. CD harus membuat perubahan baik dapat diulang.
Aliran pipa tidak menggantikan penilaian insinyur. Aliran pipa memindahkan pekerjaan yang dapat diulang dari tangan orang, merekam apa yang terjadi, dan memberikan tim jalur konsisten dari komit ke rilis.
Empat Blok Bangunan Setiap Aliran CI/CD
Aliran pipa lebih mudah dirancang ketika Anda menganggapnya sebagai urutan tanggung jawab daripada file YAML tunggal. Setiap blok menjawab pertanyaan yang berbeda.
1. Pengaktif
Pengaktif adalah lonceng pintu. A dapat memulai periksa cepat pada cabang fitur, sementara permintaan pull dapat menjalankan pintu gabungan. Event tag atau rilis dapat memulai pengemasan, dan jadwal dapat menjalankan periksa perangkat lebih luas. git push Pilih pengaktif berdasarkan risiko. Permintaan pull memerlukan feedback cepat sebelum menggabungkan. Push ke __CAPGO_KEEP_0__ mungkin membangun artefak yang dapat dijalankan. Tag rilis harus mewakili kejadian pengiriman sengaja, bukan perubahan cabang tidak sengaja.
Pilih pengaktif berdasarkan risiko. Permintaan pull memerlukan feedback cepat sebelum menggabungkan. Push ke __CAPGO_KEEP_0__ mungkin membangun artefak yang dapat dijalankan. Tag rilis harus mewakili kejadian pengiriman sengaja, bukan perubahan cabang tidak sengaja. main Pilih pengaktif berdasarkan risiko. Permintaan pull memerlukan feedback cepat sebelum menggabungkan. Push ke __CAPGO_KEEP_0__ mungkin membangun artefak yang dapat dijalankan. Tag rilis harus mewakili kejadian pengiriman sengaja, bukan perubahan cabang tidak sengaja.
1. Bangun
Proses pembangunan adalah dapur tempat sumber code berubah menjadi sesuatu yang dapat dikonsumsi oleh sistem lain. Dalam aplikasi CapacitorJS, pekerjaan ini biasanya menginstal ketergantungan yang ditentukan oleh file lock, menjalankan pembangunan web, menjalankan code, dan mengaktifkan alat pengembang platform. npx cap syncProses pembangunan iOS mungkin memanggil __CAPGO_KEEP_0__ melalui penggunaan runner macOS. Proses pembangunan Android mungkin menggunakan Gradle untuk membuat __CAPGO_KEEP_0__ atau __CAPGO_KEEP_0__.
atau xcodebuild melalui penggunaan runner macOS. Proses pembangunan Android mungkin menggunakan Gradle untuk membuat __CAPGO_KEEP_0__ atau __CAPGO_KEEP_0__. .aab Jika proses pembangunan tidak dapat direproduksi dari cek-out bersih, maka pipeline menyembunyikan ketergantungan pada mesin lokal seseorang. .apk3. Uji
Uji coba berfungsi seperti inspektur kesehatan. Uji unit memeriksa perilaku JavaScript atau TypeScript yang terisolasi. Uji integrasi memeriksa batasan seperti penyimpanan, navigasi, dan __CAPGO_KEEP_0__ klien. Uji perangkat atau emulator memeriksa plugin native, izin, tautan dalam, dan perilaku siklus hidup yang tidak dapat sepenuhnya diwakili oleh uji browser.
Tests act like a health inspector. Unit tests examine isolated JavaScript or TypeScript behavior. Integration tests check boundaries such as storage, navigation, and API clients. Device or emulator checks exercise native plugins, permissions, deep links, and lifecycle behavior that browser tests can’t fully represent.
%s %s%s 50% atau lebih banyak kasus tesStudi tersebut melaporkan lebih dari 20% waktu penyelamatan di sistemnya yang paling tidak efektif dan sekitar 50% penyelamatan median di seluruh sistem yang diperiksa ketika memilih tes yang terpengaruh, seperti yang tercatat dalam studi pengujian terus-menerus.
4. Paket
Pengemasan adalah wadah pengiriman. Pipa produksi menetapkan versi, mengumpulkan metadata, menandatangani artefak, dan menyimpan hasilnya. iOS mungkin menghasilkan IPA, sementara Android biasanya menghasilkan AAB untuk Play Console.
5. Rilis
Pengiriman adalah truk pengiriman. Pipa produksi dapat mengunggah build iOS ke TestFlight, mengirim bundle Android ke track Play internal, atau menerbitkan bundle web ke saluran pembaruan hidup yang dikendalikan. Otomatisasi pengiriman hanya membantu ketika paket dapat dipercaya dan tujuan yang jelas. Panduan otomatisasi pengiriman untuk Capacitor proyek menawarkan referensi yang berguna untuk menghubungkan langkah-langkah ini.
Jika Anda menghilangkan satu blok dan proses di sekitarnya menjadi lemah. Tanpa trigger, perubahan menunggu aksi manual. Tanpa tes, otomatisasi dapat mengirimkan kembali regresi lebih cepat. Tanpa pengemasan, tidak ada artefak yang dikendalikan untuk dipromosikan. Tanpa pengendalian pengiriman, sebuah build sukses masih bergantung pada orang yang mengulangi langkah-langkah yang rapuh.
Versi Terus Menerus vs Versi Terus Menerus
Perbedaan adalah satu batasan persetujuan, tetapi batasan tersebut mengubah profil risiko organisasi.
Dengan terus menerus menyampaikanpipeliner membangun, menguji, mengemas, dan mempersiapkan rilis. Seorang orang menyetujui aksi produksi. Tim fintech yang terregulasi mungkin mengirimkan setiap komit yang diterima secara otomatis ke staging, kemudian memerlukan manajer rilis untuk menyetujui pengiriman ke App Store atau Play Store.
Dengan terus menerus mengirimkanpipeliner melakukan rilis akhir secara otomatis setelah kebijakan melewati. Aplikasi konsumen dengan periksa otomatis yang kuat mungkin mengirimkan bundle JavaScript yang lolos ke audiens terbatas terlebih dahulu, kemudian memperluas pengiriman ketika signal kesehatan tetap dapat diterima.
| Dimensi | Pengiriman Terus-Menerus | Pengembangan Terus-Menerus |
|---|---|---|
| Keputusan Rilis | Ketika berada di halaman: Live updates product page. Peran: Judul bagian atau halaman. Kunci pesan `live_update_guidance_panel_title` (Judul Panel Panduan Live Update). | Persetujuan manusia tetap ada sebelum produksi |
| Automasi membuat keputusan rilis dari kebijakan | Kemampuan | Rapid, dengan titik kontrol eksplisit |
| Rapid ketika semua syarat wajib diotomasi | Keterbukaan | Persetujuan memberikan catatan tinjauan yang jelas |
| Log harus menangkap hasil kebijakan dan aksi rilis | A reviewer dapat menghentikan rilis yang diragukan | Kontrol roll-out dan roll-back yang progresif memiliki bobot yang lebih besar |
| Terbaik | Kategori rilis mobile yang sensitif terhadap komplian atau berisiko tinggi | Tim yang memiliki tes kuat, observabilitas, dan prosedur pemulihan |
A tim CapacitorJS yang memiliki kelompok komplian yang memerlukan tandatangan setiap rilis native akan biasanya memilih pengiriman. Pipa dapat menghasilkan IPA dan AAB, mengirimkannya ke tujuan tinjauan yang tepat, dan menunggu persetujuan. Perubahan JavaScript dan CSS yang disetujui dapat mengikuti proses pembaruan hidup terpisah ketika kebijakan organisasi memungkinkannya.
A tim game santai mungkin memilih pengiriman untuk perubahan layer web yang rendah risiko dan pengiriman untuk rilis native. Pembagian itu seringkali lebih realistis daripada memaksa satu kebijakan di setiap artefak.
Kunci perdagangan bukanlah kecepatan. Pengiriman lebih mengutamakan akuntabilitas manusia yang eksplisit, sementara Pengiriman lebih mengutamakan kemampuan sistem yang teruji untuk membuat keputusan yang konsisten. Tidak ada model yang secara otomatis lebih aman. Klik manual dapat menangkap konteks yang terlewatkan oleh tes, tetapi juga dapat menjadi bottleneck yang tidak terdokumentasi. Pengiriman otomatis dapat mengurangi delay, tetapi hanya jika tim dapat mengidentifikasi rilis yang buruk dan memulihkan versi sebelumnya tanpa improvisasi.
A Pipa Integrasi Terus-Menerus Nyata untuk Aplikasi Mobile CapacitorJS
A useful GitHub Actions workflow makes the repository’s delivery map visible. The exact action versions and signing setup will vary, but the sequence should remain understandable.
Mulai dengan repositori bersih
Push ke main dapat memicu alur aksi. Tugas pertama memeriksa commit dan memilih versi Node.js yang diperlukan. npm ci menginstal secara tepat apa yang dideklarasikan oleh file lock, yang mencegah runner dari menyelesaikan pohon dependensi yang berbeda.
Stadium validasi web kemudian dapat menjalankan perintah seperti:
- Lint: Jalankan perintah ESLint proyek dan gagal pada pelanggaran yang harus menghalangi penggabungan.
- Unit tests: Jalankan Jest dalam mode non-interaktif, kumpulkan hasil, dan simpan log yang berguna.
- Web build: Buat bundle produksi yang Capacitor akan paketkan.
- Capacitor sinkronisasi: Jalankan
npx cap syncagar proyek native menerima aset web dan perubahan plugin. - Validasi konfigurasi: Periksa bahwa konfigurasi Capacitor mengandung identifikasi aplikasi yang diharapkan, pengaturan platform, dan nilai lingkungan.
File aliran workflow mengontrol orkestrasi, sedangkan package.json mengontrol perintah proyek. Konfigurasi Capacitor mengontrol perilaku sinkronisasi. Menghindari tanggung jawab tersebut membuat kesalahan lebih mudah untuk didiagnosis. Panduan integrasi Capacitor secara terus menerus Capgo continuous integration setup guide Buat target native secara mandiri
iOS memerlukan runner macOS karena Xcode adalah bagian dari toolchain. Tugas tersebut menginstal kembali dependensi, menginstal atau mengambil sertifikat dan profil pengaturan, dan mengaktifkan
__CAPGO_KEEP_0__ xcodebuild atau Fastlane. Konfigurasi menggunakan fastlane match bisa mengelola hubungan antara materi tanda tangan dan proses pembangunan, tetapi repositori harus tidak pernah berisi sertifikat atau profil pribadi.
Android dapat menjalankan pada runner Linux atau macOS. Tugas memanggil Gradle, sering melalui perintah seperti ./gradlew bundleRelease, dan menandatangani hasil AAB dengan keystore yang dikaitkan melalui rahasia CI yang dienkripsi.
Simpan artefak dengan sengaja
Alur kerja harus mengunggah IPA dan AAB sebagai artefak yang dinamai, terkait dengan identifier komit atau rilis. Tugas-tugas lainnya dapat mengirimkan file-file tersebut yang tepat ke TestFlight atau track internal Play Console. Perbedaan ini penting karena membangun kembali setelah persetujuan dapat menciptakan artefak yang berbeda dari yang dites oleh reviewer.
Strategi matriks dapat menjalankan jalur iOS dan Android secara bersamaan. Hal ini mengurangi waktu menunggu tanpa mencampurkan kegagalan spesifik platform. Selain itu, status akhir menjadi lebih jelas: build web mungkin berhasil sementara tanda tangan Android gagal, dan alur kerja harus menunjukkan perbedaan tersebut bukan melaporkan hasil yang tidak transparan.
Rahasia harus berada di penyimpanan rahasia yang dienkripsi penyedia CI. Tugas harus menerima hanya kredential yang diperlukan, untuk durasi yang paling praktis. Log harus diperiksa untuk keluaran rahasia yang tidak sengaja, terutama ketika alat perintah baris memprint konfigurasi selama build gagal.
Menambahkan Live Updates ke Alur CI/CD Anda Dengan Capgo
A desainer mengubah salinan onboarding pada sore hari Jumat. Perubahan tersebut menyentuh JavaScript dan CSS, bukan Swift native, Kotlin, atau plugin Capacitor. Pengembang mengkomitkannya, membuka permintaan pull, dan membiarkan pengecekan normal memvalidasi bundle web.
Setelah npm ci, pembangunan web, tes, dan npx cap sync sukses, pekerjaan rilis dapat menerbitkan aset web yang dihasilkan ke saluran Capgo yang dipilih. Saluran tersebut mungkin mewakili tahap pengujian, produksi, audiens beta, atau kelompok yang dikendalikan lainnya. Pengguna menerima bundle melalui mekanisme pembaruan aplikasi daripada menunggu binary toko baru.
Pemisahan penting adalah code native. Perubahan pada JavaScript, CSS, salinan, atau konfigurasi yang kompatibel dapat mengikuti jalur pembaruan hidup. Perubahan pada plugin native, izin, hak istimewa, atau platform code masih memerlukan binary iOS atau Android baru dan proses toko yang relevan.
Anggap saluran sebagai kontrol rilis
Saluran pengujian memungkinkan tim memvalidasi bundle dengan audiens yang dikendalikan sebelum promosi produksi. Penguncian versi dapat menjaga versi aplikasi yang diketahui pada bundle yang kompatibel sementara binary native yang lebih baru menggunakan jalur rilis yang berbeda. Pemisahan tersebut membantu menghindari mengirimkan code web ke runtime native yang tidak memahaminya.
A rollback harus memulihkan bundle yang diketahui baik, bukan memerlukan pengembang untuk membangun kembali build sebelumnya secara manual. Nilai operasional berasal dari menghubungkan publikasi, riwayat versi, target audiens, dan status pengiriman ke proses rilis yang sama.
Publikasikan setelah validasi
Langkah Capgo CLI ini termasuk setelah build web normal dan periksa. Penggunaan autentikasi harus menggunakan rahasia CI atau variabel lingkungan yang dilindungi, dan publikasi produksi harus dibatasi pada cabang, tag, atau kebijakan persetujuan yang mewakili rilis sengaja.
Langkah Capgo GitHub Panduan Integrasi Aksi menunjukkan bagaimana langkah publikasi tersebut dapat masuk ke dalam alur kerja otomatis. Prinsip yang lebih luas berlaku tanpa peduli penyedia: bangun sekali, validasi artefak, publikasikan ke lingkungan yang dinamai, dan simpan metadata yang cukup untuk mengidentifikasi secara tepat apa yang diterima pengguna.
Untuk tim, ini menciptakan dua jalur yang terhubung. Jalur toko mendistribusikan kemampuan native. Jalur live-update mendistribusikan perubahan layer web yang disetujui. Menghindari perbedaan jalur tersebut mencegah kesalahan umum yang menganggap setiap Capacitor perubahan sebagai rilis toko penuh atau shortcut yang tidak terkendali.
Keamanan dan AI di Pipa CI/CD Hari Ini
Kecepatan pipa tidak dapat menggantikan kontrol rilis yang lemah. Alur kerja mobile mengelola kunci tanda tangan, dependensi pihak ketiga, alat build native, dan code yang dapat mencapai perangkat pengguna. Keamanan harus berada di dalam jalur otomatis yang sama seperti linting dan tes.
Kontrol-kontrol berguna termasuk pengecekan dependensi dengan npm audit atau Snyk, deteksi rahasia dengan gitleaks, pembuatan SBOM, artefak native yang ditandatangani, izin CI yang dibatasi, dan lingkungan produksi yang dilindungi. Pembaruan hidup juga memerlukan verifikasi tanda tangan dan pengendalian saluran, sehingga aplikasi yang valid dapat menolak konten yang dimanipulasi atau tidak kompatibel.
Sebuah studi tahun 2026 tentang GitHub Actions menemukan bahwa lima langkah keamanan yang direkomendasikan memiliki tingkat implementasi rata-rata hanya 17,5% di sekitar 340.000 repositori publik, sedangkan survei terhadap 102 pengembang menemukan kurangnya kesadaran dan beban operasional yang diharapkan sebagai penghalang utama, menurut temuan keamanan CircleCI yang dilaporkan. Perbedaan ini menunjukkan bahwa tim seringkali membutuhkan rencana adopsi yang lebih sederhana daripada produk keamanan lainnya.
Jangan pisahkan AI yang berguna dari teater pipa
AI dapat membantu menyajikan log yang gagal, mengelompokkan kegagalan tes yang berulang, menulis catatan rilis, dan menganjurkan kesalahan konfigurasi yang mungkin. Penggunaan-penggunaan tersebut menjaga manusia bertanggung jawab atas keputusan dan membuat output mudah untuk diverifikasi.
Klaim tentang pipa yang dapat menyembuhkan diri sendiri memerlukan lebih banyak peringatan. Survei industri tahun 2026 melaporkan bahwa 73% organisasi tidak menggunakan AI di pipa mereka, sedangkan 60% mengutip nilai atau kasus penggunaan yang tidak jelas, 36% mengutip ketidakpercayaan terhadap hasil yang dihasilkan, dan 33% mengutip kekhawatiran privasi, seperti yang dijelaskan dalam laporan survei TeamCity Praktik.
| Adopsi Sekitar | Matang | Aksi Tindakan Keamanan __CAPGO_KEEP_0__ |
|---|---|---|
| Recommended GitHub Actions security measures | Kesadaran dan kesenjangan operasional | AI di Pipa CI/CD |
| 27% adopsi | Penggunaan yang tidak jelasberdasarkan 73% laporan tidak digunakan | Pengujian selektif |
| Kemudahan nilai AI di kalangan pengguna non | 60% menyebutkan kasus penggunaan yang tidak jelas atau nilai | Masalah Evaluasi |
| Kepercayaan pada hasil yang dihasilkan AI | 36% menyebutkan kurangnya kepercayaan | Ulasan manusia tetap penting |
Angka-angka tidak boleh menjadi alasan untuk menunda perlindungan dasar. Mulai dengan perlindungan rahasia, visibilitas dependensi, tanda tangan, dan akses dengan hak yang paling rendah. Tambahkan AI di mana ia mengurangi upaya investigasi tanpa memungkinkan output model yang tidak diverifikasi untuk mengesahkan rilis produksi. Pedoman keamanan pipeline untuk aplikasi Capacitor bisa membantu mengatur kontrol di sekitar risiko spesifik mobile.
Daftar Periksa Kematangan untuk Pengaturan CI/CD Anda
A pipa yang matang bukanlah yang memiliki banyak tugas. Itu adalah yang memberikan tim bukti yang dapat diandalkan pada setiap batas rilis.
Tinjau alur kerja, bukan YAML
Pakai titik kontrol ini untuk menilai sistem yang dioperasikan.
- Triggers yang dikonfigurasi: Setiap permintaan pull dan push relevan memulai alur kerja yang diharapkan. Tanda adalah jalankan yang terlihat yang terikat pada komit, bukan niat yang didokumentasikan.
- Uji coba otomatis mengunci penggabungan: Lint dan uji unit harus melewati sebelum penggabungan. Dalam GitHub, periksa status yang diperlukan harus mencegah penggabungan ketika tugas gagal.
- Artifak yang ditandatangani disimpan: Alur kerja menciptakan file IPA dan AAB yang ditandatangani dan menyimpannya bersama metadata bangun yang dapat diidentifikasi. Rilis yang lebih lanjut harus menggunakan artifak yang disimpan daripada membangun ulang dari memori.
- Lingkungan yang terpisah: Staging dan produksi menggunakan kredit yang berbeda, saluran, dan aturan persetujuan. Pengaliran staging tidak boleh dapat menerbitkan secara tidak sengaja ke produksi.
- Jalan pengaliran otomatis: Aliran pipa dapat mengirimkan artefak yang disetujui ke tujuan yang ditentukan tanpa seseorang mengcopy file antara mesin.
- Siap untuk diulang: Tim dapat memulihkan versi sebelumnya native atau web-layer melalui aksi yang dokumentasi. Prosedur ulang yang hanya ada di catatan seorang insinyur bukanlah siap untuk dioperasikan.
- Pantauan dan peringatan: Tim mengikuti durasi pipa, jalankan yang gagal, hasil pengiriman, dan kesehatan aplikasi. Suatu pekerjaan sukses tidak membuktikan bahwa pengguna menerima atau menoleransi pembaruan.
Perbaiki celah yang paling menyakitkan terlebih dahulu
Tidak ubah daftar periksa menjadi proyek platform selama setahun. Pilih kemampuan yang hilang yang menghalangi rasa sakit yang paling sering, perbaiki dalam satu sprint, dan jalankan daftar periksa lagi.
Jika pengembang menunggu bangun manual, otomatisasikan bangun. Jika gabungan rusak karena tes berjalan terlalu lambat, buat cek yang wajib. Jika rilis JavaScript yang buruk memaksa pengiriman toko, dokumentasikan dan lindungi jalur pembaruan hidup di mana produk dan kebijakan komplian Anda memungkinkannya.
Aturan insinyur senior: Aliran pipa matang ketika insinyur yang berbeda dapat mengoperasikannya dengan aman selama insiden.
Standar itu mengekspos titik lemah dengan cepat. Tanda centang hijau hanya berarti jika tim tahu apa yang divalidasi, ke mana artefak pergi, bagaimana pengguna menerima, dan bagaimana mengembalikan jika perilisan berperilaku buruk.
Capgo menghubungkan aliran kerja CI/CD CapacitorJS ke pengiriman live-update yang dikendalikan, dengan bundle web yang ditandatangani, saluran, riwayat versi, dan dukungan rollback untuk perubahan JavaScript dan aset yang layak. Kunjungi Capgo to see how it can fit alongside your existing GitHub Actions, store, and release processes.
