Bagaimana Rapido Cloud mengelola Rilis Semantik dengan __CAPGO_KEEP_0__ CapacitorUpdater
1. PendahuluanDi Rapido Cloud (), I am developing a mobile application for Salesforce clients to easily deploy their own branded mobile application without having to go through the difficult loops of using the Salesforce Mobile SDK or the Salesforce Mobile Publisher.
Kami telah mengembangkan aplikasi seluler ini di atas platform modern dan "standar" dengan komponen dan alat yang luas, termasuk Ionic 8, Angular 18, TypeScript, Capacitor dan sekarang Capgo CapacitorUpdater. Ini lebih mudah untuk dihandle oleh klien yang tidak ingin mengelola spesifik Salesforce platform seperti Lightning Web Components; dan lebih mudah dan lebih murah bagi saya untuk merekrut pengembang dan pemelihara Ionic + Angular aplikasi seluler.
Artikel ini menjelaskan desain, pilihan, dan implementasi saya yang membuat Capgo dan semantic-release sukses tanpa perlu dipikirkan untuk mengelola semua pengiriman otomatis melalui Github Actions. Semua ini dirancang, diuji, dan dokumentasi selama periode uji coba gratis 14 hari yang menyenangkan dari Capgo CapacitorUpdater.
2. Mengapa menggunakan Capgo ? Mengapa menggunakan semantic-release ?
Capgo CapacitorUpdater menarik perhatian saya dengan janji untuk membuat pengiriman aplikasi seluler lebih sederhana, lebih cepat, dan lebih fleksibel daripada proses pengiriman standar Apple AppStore/Google PlayStore.
Saya sangat takut akan kurva belajar untuk membuat ini sukses, tetapi saya berhasil mengirimkan aplikasi saya ke Apple TestFlight dengan mudah. Saya kemudian dapat menggunakan Capgo CapacitorUpdater untuk mengirimkan update saya lebih cepat.
My first requirement and test case was to deploy for myself to test my app as a real mobile app on my own phone, instead of testing in a mobile emulator or in a simulator via the Nexus mobile browser suggested by IIonic. That’s because my app uses native features such as Geolocation or accessing the Photo Gallery and Camera. Not having the past experience of testing a Capacitor mobile app, I wasn’t sure if everything was going to work properly : nothing better than to test the real app, in real conditions !
Jadi Capgo CapacitorUpdater membantu saya memperbarui aplikasi saya di ponsel saya, secara langsung, 1 menit setelah menyimpan fitur baru atau perbaikan di kode sumber code : begitu mengalir, begitu fleksibel, dan mudah untuk diatur !
3. Model cabang dan rilis saya, dan bagaimana semantic-release terintegrasi
Jadi sekarang saya memiliki pengiriman ke Capgo server bekerja dengan benar, saya perlu mengotomatisasi ini dan mengintegrasikannya ke dalam pipeline CI/CD saya.
Ini adalah cara saya mengorganisir model cabang dan rilis saya
Untuk setiap aplikasi, baik seluler, web, atau Salesforce :
- pengembangan berlangsung di
feature/...cabang yang diambilmain, dan mereka diintegrasikan kemainyang merupakan acuan untuk sebagian besar cabang pengembangan, di luar perawatan dan fitur khusus untuk pengiriman kustom (lebih lanjut tentang ini di bawah) - pengiriman diaktifkan menggunakan cabang rilis yang mungkin adalah :
production, cabang rilis pra-rilis (alpha,beta,nightly, dan lain-lain) serta cabang khusus pelanggan atau konteks untuk pengiriman khusus - pengiriman diluncurkan oleh permintaan pull permintaan pull yang sedang diintegrasikan ke cabang pengiriman. Saya tidak menggunakan pengiriman yang diaktifkan oleh tag karena semantic release mengelola tag dan semua yang lain untuk saya.
Secara dasarnya, ini adalah Gitlab Flow :

Gitlab Flow - sumber https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Catatan sampingan tentang bagaimana semantic-release bekerja :
Dalam cabang pengiriman, ketika semantic-release diaktifkan, maka akan secara otomatis menghitung nomor versi baru di cabang ini, tergantung pada nomor versi sebelumnya di cabang dan perbaikan atau fitur yang diberikan. Perbaikan akan membuat versi patch baru, sedangkan fitur akan membuat versi minor baru. Selain itu, juga secara otomatis termasuk prerelease alpha, betadan lain-lain dalam nomor versi.
Semantic release menghasilkan daftar perubahan dari komit Anda, mengelompokkan perbaikan dan fitur sesuai dengan definisi komit konvensional (lihat https://www.conventionalcommits.org/en/about) dan dikonfigurasi dalam semantic release.
It juga akan memperbarui semua pull request (Github, di kasus saya) yang sudah diintegrasikan dan masalah terkait dengan komentar yang menghubungkannya ke tag dan rilis. Akhirnya, dalam rilis ini Github, itu akan menambahkan aset seperti kode code, biner jika perlu, CHANGELOG.mddan lain-lain.
4. Cabang, rilis/prereleases, saluran dalam semantic release dan di Capgo
Jadi apa yang saya inginkan semantic release untuk melakukan untuk Capgo deployments adalah sebagai berikut.
Saya ingin semantic release menghasilkan nomor versi
Capgo telah mengembangkan dan mendokumentasikan versi mereka sendiri dari “Conventional Commits” standard-version alat, dengan forked repo mereka standard-version (https://github.com/Cap-go/standard-versiondan juga mereka capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionjuga capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionrepos. Mereka telah mendokumentasikan pada blog mereka skema versi yang digunakan oleh Capgo dalam penggunaan mereka (https://capgo.app/blog/how-version-work-in-capgo/)Sekarang, JavaScript bundle mengikuti versi semver "Semantic Versioning" (https://semver.org semantic-release ) yang
juga mengikuti (tentu saja !) semantic-release Jadi itu sangat bagus, dan merupakan kelegaan bagi saya karena saya menggunakan secara luas.
I juga ingin rilis semantik menghasilkan pengiriman aplikasi pada saluran yang berbeda
As yang disebutkan di atas, saya perlu mengirimkan versi rilis sebelumnya dari cabang seperti alpha, beta, nightly Saya perlu mengirimkan versi rilis sebelumnya dari cabang seperti production-customer-jones, production-customer-doe, dll
Capgo menyediakan fitur “saluran” yang tepat apa yang juga didukung oleh rilis semantik, jadi saya sangat bersemangat untuk membuat mereka bekerja sama. Fitur ini juga sesuai dengan pengiriman cabang yang berbeda yang dikelola oleh XCode Cloud (lihat lebih lanjut tentang ini di bawah).
Nomor versi Semver yang dihasilkan oleh rilis semantik pada rilis sebelumnya seperti 1.0.0-alpha.1Nomor versi Semver yang dihasilkan oleh rilis semantik pada rilis sebelumnya seperti 1.0.0-alpha.2, etc. Although not documented explicitly, these version numbers are supported by Capgo, which is great news for me : I will use semantic release channels and prerelease to generate versions of my app with Capgo channels.
, dll. Meskipun tidak secara eksplisit dokumentasi, nomor versi ini didukung oleh Capgo, yang merupakan berita baik bagi saya : saya akan menggunakan saluran rilis semantik dan rilis sebelumnya untuk menghasilkan versi aplikasi saya dengan __CAPGO_KEEP_1__ saluran.
To automate deployment of your app bundles to Capgo, you need to use the Capgo CLI command bundle uploadUntuk mengautomatisasi pengiriman paket aplikasi Anda ke __CAPGO_KEEP_0__, Anda perlu menggunakan perintah __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ npx @capgo/cli@latest bundle upload --help . Ketikkan perintah ini untuk mendapatkan banyak pilihan unggah. Di antara pilihan tersebut, kita akan menggunakan pilihan berikut :
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID
- CHANNEL adalah Capgo saluran yang ingin kita buat untuk mendeploy (misal
alpha) - VERSION adalah yang dihasilkan oleh semantic release (misal
1.0.0-alpha.1) - CAPGO_APIKEY disediakan oleh Capgo untuk mengidentifikasi unik login pipeline CI/CD Anda
- CAPGO_APPID disediakan oleh Capgo untuk mengidentifikasi aplikasi Anda (misal
com.mystartup.mysuperapp)
6. Pengaturan semantic release + Capgo CapacitorUpdate saya
Akhirnya, bagaimana semua ini terintegrasi?

Versi aplikasi bundel yang dibuat dengan semantic release dan Github Actions
Automasi release semantic dengan Github Actions
Keindahan dari release semantic adalah bahwa otomatisasi pengiriman, dalam bentuk Github workflow Action, sangat sederhana. Ini akan terlihat sangat mirip di platform CI/CD lain.
# ./github/workflows/release.yml
name: Release
on:
workflow_dispatch:
push:
branches: [alpha, alpha-nocapgo, dev-rupert] # <--- adapt this
env:
CAPGO_APPID: com.mystartup.mysuperapp # <--- adapt this
CAPGO_APIKEY: ${{ secrets.CAPGO_APIKEY }}
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
cache: "npm"
- run: npm install
- run: npx semantic-release
env:
DEBUG: true
GITHUB_TOKEN: ${{ github.token }}
Ini hanya menginstal lingkungan NodeJS, kemudian memanggil release semantic.
Untuk setiap mzerge di cabang yang terdaftar di branchesJika Anda mengaktifkan rilis semantik, maka rilis semantik akan mengaktifkan pengiriman.
Tetapkan CAPGO_APIKEY di rahasia repository Anda.
Perbarui CAPGO_APPID di sini.
Karena perilaku rilis semantik ditentukan oleh .releaserc.json konfigurasi file.
// .releaserc.json
{
"branches": [
{
"name": "release",
"channel": "production"
},
{
"name": "alpha",
"channel": "alpha",
"prerelease": "alpha"
},
{
"name": "alpha-nocapgo",
"channel": "alpha",
"prerelease": "alpha-nocapgo"
},
{
"name": "dev-rupert",
"channel": "development",
"prerelease": "development"
},
{
"name": "dev-paul",
"channel": "development",
"prerelease": "development"
}
],
"ci": true,
"debug": true,
"dryRun": false,
"repositoryUrl": "https://github.com/RupertBarrow/mysuperapp",
"verifyConditions": ["@semantic-release/github"],
"plugins": [
[
"@semantic-release/commit-analyzer",
{
"preset": "angular",
"releaseRules": [
{ "type": "breaking", "release": "major" },
{ "type": "feat", "release": "minor" },
{ "type": "fix", "release": "patch" },
{ "type": "ci", "release": "patch" },
{ "type": "doc", "release": "patch" },
{ "type": "docs", "release": "patch" },
{ "type": "refactor", "scope": "core-*", "release": "minor" },
{ "type": "refactor", "release": "patch" },
{ "scope": "no-release", "release": false }
]
}
],
"@semantic-release/release-notes-generator",
["@semantic-release/changelog", { "changelogFile": "CHANGELOG.md" }],
[
"@semantic-release/git",
{
"assets": ["package.json", "CHANGELOG.md", "ios/App/App.xcodeproj/project.pbxproj"],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
}
],
["@semantic-release/github", { "assets": ["CHANGELOG.md"] }],
[
"@semantic-release/exec",
{
"prepareCmd": "npm run build",
"publishCmd": "npm add -D @capgo/cli && npx @capgo/cli bundle upload --channel ${branch.channel} --apikey $CAPGO_APIKEY --bundle ${nextRelease.version} --bundle-url $CAPGO_APPID"
}
]
]
}
branches:branchesBerikut adalah pengaturan saya, dijelaskan di bawah ini :name), mapped to the Capgo channel (channelyang diterjemahkan ke saluran __CAPGO_KEEP_0__ (prerelease) dan bagaimana versi prerelease akan disebut (branch.prerelease = "development"). Misalnya, jikax.y.z-development.n- versi yang dihasilkan oleh rilis semantik akan menjadi
alphapengiriman ke saluran (dan saluran lainnya).alpha-nocapgocabang akan mengirimkan aplikasi ke saluranalphatetapi dengan nama prerelease yang berbeda dalam nomor versi - mengirimkan ke cabang pengembang
dev-rupertataudev-paulakan mengirimkan ke saluran di __CAPGO_KEEP_0__, semua dengan kata kunci prerelease yang sama dalam nomor versidevelopment: pada tahap pertama dari rilis semantik, itu memeriksa bahwa memiliki akses yang benar ke Capgo. Saya berharap dapat menambahkan pengecekan autentikasi untuk __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ di sini kemudiandevelopment: hal-hal standar rilis semantik - lihat dokumentasi mereka (
verifyConditions: in the first stage of semantic release, it checks that it has the correct access to Github. I hope to add an authentication check for the Capgo CLI here later@semantic-release/commit-analyzer: menghasilkan file riwayat perubahan sebagaihttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generatoratauCHANGELOG.md@semantic-release/gitdeployments ke cabang pengembangpackage.json,CHANGELOG.mddanios/App/App.xcodeproj/project.pbxproj- Saya tidak membangun untuk Android, padahal)@semantic-release/github: lampirkan file ke rilis __CAPGO_KEEP_0__ sebagai asetCHANGELOG.mdfile to the Github release as an asset@semantic-release/exec) dan kemudian untuk membangun dan mengdeploy bundle aplikasi ke server __CAPGO_KEEP_0__ ('prepareCmdKamu akan melihat bahwa tidak ada yang perlu dijelaskan tentang cara menghitung dan meningkatkan versi, cara membuat changelog, tag atau rilis Capgo, dll. : segalanya diatur secara otomatis oleh semantic release dengan konfigurasi minimal.publishCmd)
You will notice that their is no fiddling around with explaining how we want the version number to be calculated and incremented, how we need to generate a changelog, a Github tag or release, etc. : everything is handled by default by semantic release, with minimal configuration.
Mengintegrasikan semua ini dengan XCode Cloud untuk membangun versi baru dari aplikasi biner sangatlah mudah (Saya belum mengdeploy ke Google Play, tapi pembangunan untuk Google Play seharusnya sama) :
Saya mengatur proses XCode Cloud untuk membangun ketika ada perubahan pada cabang yang saya inginkan (misalnya
- Saya mengatur XCode Cloud untuk membangun hanya ketika file ini diperbarui. File ini diperbarui setelah setiap versi yang dihasilkan oleh semantic release
production) - integrasi
CHANGELOG.mdsemua - Saya dapat memicu bangunan pada cabang yang berbeda untuk meniru pengiriman untuk saluran yang berbeda.
branch.channelSaya mengatur variabel lingkungan secara manual dengan nilai darireleaserc.json(ya, ini adalah duplikasi manual) dan kemudian, jika saya ingin, saya dapat mengirimkan aplikasi AppStore yang berbeda untuk setiap aplikasi pelanggan yang disesuaikan yang dijalankan dari cabang rilis yang disesuaikan, seperti yang disebutkan sebelumnya.

Membangun biner aplikasi di XCode Cloud dengan Capgo saluran
7. Kesimpulan
Kesimpulan, saya sangat senang telah dapat mengintegrasikan Capgo CapacitorUpdater ke dalam pipeline rilis semantik standar saya, dengan cepat dalam jangka waktu 14 hari trial, dan hasilnya adalah sebagai berikut:
- Nomor versi bundle dihasilkan secara otomatis oleh rilis semantik dan kompatibel dengan Capgo server
- Rilis semantik secara otomatis mengirimkan bundle aplikasi Capgo, juga menggunakan Capgo saluran
- ini sangat sesuai dengan bangunan XCode Cloud dari biner aplikasi
Langkah selanjutnya
Saya sedang dalam fase pengembangan aplikasi ini. Saya akan segera membuatnya tersedia untuk tester melalui TestFlight (untuk iOS). Mengingat kekuatan Capgo, saya akan pasti mengirimkan versi gratis aplikasi ke AppStore untuk tes, yang akan diperbarui secara teratur dengan Capgo selama tes. Saya akan kemudian mengirimkan versi lain (berbayar) aplikasi ke AppStore, di bawah rekaman lain, dan juga memperbarui itu secara teratur dengan Capgo.
I harapkan dapat menambahkan verifikasi pra-build yang lebih baik untuk Capgo bundle upload prasyarat ke konfigurasi rilis semantik saya.
Saya memiliki sekarang sebuah pipeline rilis semantik yang bersih, sederhana, dan dapat diulang untuk aplikasi mobile masa depan yang dikembangkan dengan Ionic + Angular + Capacitor.
Pengarang - Rupert Barrow
Saya memiliki lebih dari 22 tahun pengalaman dengan Salesforce, sebagai klien dan pengguna, sebagai mitra dan integrator, arsitek, pengembang, analis bisnis, dan konsultan. Saya mendirikan dan mengelola Altius Services sebagai COO dan CTO selama 13 tahun, sebuah mitra SI Salesforce sukses di Perancis, sebelum melanjutkan petualangan baru sebagai solopreneur Salesforce dengan produk saya Rapido Cloud Anda dapat menemukan saya di LinkedIn di
https://linkedin.com/in/rbarrow Anda dapat melihat penawaran Salesforce kami di .
https://www.rapido-companion.app dan context: Halaman/area: Situs web pemasaran Capgo. Peran: Label UI singkat atau item navigasi. Dilihat di: halaman trust.astro. Kunci pesan `dan` (Dan). https://www.rapido.cloud (dalam pengembangan).
Teruskan dari Cara Rapido Cloud Mengelola Capgo Pembaruan Semantik dengan CapacitorUpdater
Jika Anda menggunakan Cara Rapido Cloud Mengelola Capgo Pembaruan Semantik dengan CapacitorUpdater untuk merencanakan pengiriman pembaruan hidup, hubungkannya dengan Capgo Pembaruan Hidup for the product workflow in Capgo Live Updates, untuk alur kerja produk di __CAPGO_KEEP_0__ Pembaruan Hidup, Ringkasan untuk detail implementasi di Ringkasan, Fitur-Fitur Perilaku Pembaruan untuk detail implementasi di Perilaku Pembaruan, dan Jenis Pembaruan untuk detail implementasi di Jenis Pembaruan.