1. Pengenalan
At Rapido Cloud (www.rapido.cloudSaya sedang mengembangkan sebuah aplikasi seluler untuk klien Salesforce agar dapat dengan mudah mengdeploy aplikasi seluler yang terbranding sendiri tanpa harus melewati loop yang sulit menggunakan Salesforce Mobile SDK atau Salesforce Mobile Publisher.
Saya telah mengembangkan aplikasi seluler ini pada 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 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 berpikir keras untuk mengelola semua deployments secara otomatis melalui Github Actions. Semua ini dirancang, diuji dan dokumentasi selama periode uji coba gratis 14 hari dari Capgo CapacitorUpdater.
2. Mengapa menggunakan Capgo ? Mengapa menggunakan semantic-release ?
Capgo CapacitorUpdater menarik perhatian saya dengan janji untuk membuat proses pengiriman aplikasi seluler lebih sederhana, lebih cepat dan lebih fleksibel daripada proses pengiriman standar Apple AppStore/Google PlayStore.
Saya awalnya takut dengan kurva belajar untuk membuat ini sukses tapi saya berhasil menginstal aplikasi saya ke Apple TestFlight dengan mudah. Saya kemudian dalam posisi untuk menggunakan Capgo CapacitorUpdater untuk menginstal 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 mengupdate aplikasi saya di ponsel saya, secara langsung, 1 menit setelah menyimpan fitur baru atau perbaikan di sumber code : begitu menghibur, dan begitu fleksibel, dan mudah untuk diatur!
3. Model cabang dan rilis saya, dan bagaimana semantic-release berada di dalamnya
Sekarang saya telah menginstal aplikasi saya ke Capgo server dengan benar, saya perlu mengotomatisasi ini dan memasukkannya ke dalam pipeline CI/CD saya.
Ini adalah cara saya mengorganisir model cabang dan rilis saya
Untuk setiap aplikasi, baik mobile, web, atau Salesforce :
- pengembangan berlangsung di
feature/...cabang yang diambil darimain, dan mereka diintegrasikan kemainyang merupakan acuan untuk cabang pengembangan sebagian besar, di luar perawatan dan fitur khusus untuk pengiriman khusus (lebih lanjut tentang ini di bawah) - Deploymen ini dipicu oleh berasal dari cabang rilis yang mungkin adalah :
production, cabang rilis pra-rilis (alpha,beta,nightly, dll.) dan juga cabang khusus pelanggan atau konteks untuk pengiriman khusus - Deploymen dipicu oleh permintaan pull masuk ke cabang pengiriman. Saya tidak menggunakan pengiriman yang dipicu oleh tag karena semantic release mengelola tag dan semua yang lain untuk saya.
Secara sederhana, 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 :
In cabang pengembangan, ketika semantic-release diaktifkan, maka akan secara otomatis menghitung nomor versi baru pada cabang ini, tergantung pada nomor versi sebelumnya pada tag cabang dan perbaikan atau fitur yang disampaikan. Perbaikan akan membuat versi patch baru, sedangkan fitur akan membuat versi minor baru. Ini juga secara otomatis termasuk prerelease alpha, betadan lain-lain dalam nomor versi.
Semantic release menghasilkan daftar perubahan dari komit Anda, mengelompokkan perbaikan dan fitur seperti yang ditentukan dalam komit konvensional (lihat https://www.conventionalcommits.org/en/about) dan dikonfigurasi dalam semantic release.
Juga akan memperbarui semua pull request dan masalah terkait yang sudah diintegrasikan ke dalam Github dan menghubungkannya ke tag dan rilis. Akhirnya, dalam rilis ini Github, akan menambahkan aset seperti code, biner jika perlu, CHANGELOG.mddan lain-lain.
4. Cabang, rilis/prerelease, saluran dalam semantic release dan di Capgo
Jadi apa yang saya inginkan semantic release untuk lakukan pada Capgo pengembangan 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 repositori mereka yang di- fork standard-version (https://github.com/Cap-go/versi-standar), dan versi mereka sendiri capacitor-standard-version (https://github.com/Cap-go/capacitor-versi-standar) juga termasuk capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standar-versi) repositori. Mereka telah mendokumentasikan pada blog mereka skema versi yang digunakan oleh Capgo dalam penggunaan mereka (https://capgo.app/blog/cara-versi-bekerja-di-capgo/) Bundel JavaScript mengikuti versi semver 'standar' 'Semantic Versioning' (https://semver.org) yang juga mengikuti (tentu saja !) semantic-release So itu bagus, dan merupakan kelegaan bagi saya karena saya menggunakan
]} semantic-release secara luas.
Saya juga ingin semantik release menghasilkan pengiriman aplikasi pada saluran yang berbeda.
Sebagaimana disebutkan di atas, saya perlu mengirimkan versi prerelease dari cabang seperti alpha, beta, nightly dan lain-lain. production-customer-jones, production-customer-doetetapi juga versi khusus pelanggan pada cabang seperti
Capgo provides the “channels” feature which is exactly what semantic release also supports, so I am excited to make them work together. These also fit in with the different branch builds managed by XCode Cloud (see more about this below).
__CAPGO_KEEP_0__ menyediakan fitur “saluran” yang tepat apa yang juga didukung oleh semantik release, 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). 1.0.0-alpha.1Nomor versi semver yang dihasilkan oleh semantik release pada prereleases 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.
5. How can I use Capgo to release my application ?
To automate deployment of your app bundles to Capgo, you need to use the Capgo CLI command bundle uploadMeskipun tidak secara eksplisit dokumentasi, nomor versi ini didukung oleh __CAPGO_KEEP_0__, yang merupakan berita baik bagi saya : saya akan menggunakan saluran semantik release dan prerelease untuk menghasilkan versi aplikasi saya dengan __CAPGO_KEEP_1__ saluran dan __CAPGO_KEEP_2__ saluran. npx @capgo/cli@latest bundle upload --help untuk mendapatkan berbagai pilihan unggah.
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL is the Capgo channel to which we want to deploy (eg
alpha) - CHANNEL adalah saluran __CAPGO_KEEP_0__ ke mana kami ingin mengirimkan (misalnya
1.0.0-alpha.1) - CAPGO_APIKEY is provided by Capgo to uniquely identify your CI/CD pipeline login
- CAPGO_APIKEY disediakan oleh Capgo untuk mengidentifikasi unik login pipeline CI/CD Anda
com.mystartup.mysuperapp)
Capgo_APPID disediakan oleh __CAPGO_KEEP_1__ untuk mengidentifikasi unik aplikasi (misalnya
6. Konfigurasi semantic release + __CAPGO_KEEP_0__ CapacitorUpdate saya
Versi aplikasi bundel yang dibangun dengan semantic release dan Github Actions
Versi aplikasi bundel yang dibangun dengan semantic release dan Github Actions
Automasi release semantic dengan Github Actions
# ./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 }}Keindahan dari release semantic adalah bahwa otomatisasi pengiriman, dalam bentuk alur kerja __CAPGO_KEEP_0__ Actions, sangat sederhana. Ini akan terlihat sangat mirip di platform CI/CD lainnya.
For setiap merge ke cabang yang terdaftar di branches, rilis semantik akan mengaktifkan proses deploy.
Atur CAPGO_APIKEY di rahasia repository Anda.
Perbarui CAPGO_APPID di sini.
perilaku rilis semantik ditentukan di file konfigurasi. .releaserc.json Konfigurasi file ini menjelaskan pengaturan cabang (
// .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:branches), yang dikaitkan dengan saluran __CAPGO_KEEP_0__ (name), mapped to the Capgo channel (channel) . Misalnya, jikaprereleasenomor versi yang dihasilkan oleh rilis semantik akan menjadibranch.prerelease = "development"proses deploy kex.y.z-development.n- deployments to the
alphadanalpha-nocapgocabang akan mengirimkan aplikasi ke saluran, tetapi dengan nama prerelease yang berbeda dalam nomor versialphaatau - akan mengirimkan ke saluran pada __CAPGO_KEEP_0__, semua dengan kata kunci prerelease yang sama dalam nomor versi
dev-rupert: pada tahap pertama dari rilis semantik, ia memeriksa apakah memiliki akses yang benar ke __CAPGO_KEEP_0__. Saya berharap dapat menambahkan pengecekan autentikasi untuk __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ di sini kemudiandev-paul: hal-hal standar rilis semantik - lihat dokumentasi mereka (developmenthttps://Capgo.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formatdevelopment: menghasilkan file riwayat perubahan sebagai
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-analyzersaluran pada __CAPGO_KEEP_0__, semua dengan kata kunci prerelease yang sama dalam nomor versihttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generatorsaluranCHANGELOG.md@semantic-release/git: komit berikutnya file yang telah diperbarui oleh Ionic build aplikasi dan oleh pekerjaan semantic release (package.json,CHANGELOG.mddanios/App/App.xcodeproj/project.pbxproj- Saya tidak membangun untuk Android, belum@semantic-release/github: tambahkan 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__ (prepareCmdAnda akan melihat bahwa tidak ada fiddling dengan menjelaskan bagaimana kita ingin versi nomor untuk dihitung dan ditingkatkan, bagaimana kita perlu menghasilkan log perubahan, tag Capgo atau rilis, 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 membangun versi baru dari aplikasi biner adalah sederhana (Saya belum mengdeploy ke Google Play, tetapi pembangunan itu seharusnya sama) :
Saya mengatur proses XCode Cloud untuk membangun ketika ada perubahan pada cabang yang saya inginkan untuk digunakan (misalnya
- Saya mengatur XCode Cloud untuk membangun hanya ketika
production) - ada perubahan pada cabang tersebut
CHANGELOG.mdFile telah diperbarui. Ini diperbarui setelah setiap versi yang dihasilkan oleh rilis semantik - Saya dapat memicu pembangunan pada cabang yang berbeda untuk meniru pengiriman untuk saluran yang berbeda. Pada setiap konfigurasi pembangunan XCode Cloud pada cabang yang berbeda, saya menetapkan variabel lingkungan secara manual dengan nilai dari
branch.channelDitetapkan padareleaserc.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 diunduh dari cabang rilis yang disesuaikan, seperti yang disebutkan sebelumnya.
Membangun biner aplikasi pada 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 percobaan, dan hasilnya adalah sebagai berikut :
- Nomor versi bundle dihasilkan secara otomatis oleh rilis semantik dan kompatibel dengan Capgo server
- Rilis semantik mengirimkan bundle aplikasi Capgo secara otomatis, juga menggunakan Capgo saluran
- ini sangat sesuai dengan pembangunan XCode Cloud biner aplikasi
Langkah selanjutnya
Saya sedang dalam fase pengembangan aplikasi ini. Aplikasi ini akan segera saya buat tersedia bagi tester melalui TestFlight (untuk iOS). Mengingat kekuatan Capgo, saya pasti akan mengeluarkan versi gratis aplikasi ini ke AppStore untuk tes, yang akan diperbarui secara teratur dengan Capgo selama tes. Kemudian saya akan mengeluarkan versi lain (berbayar) aplikasi ini di AppStore, di bawah catatan lain, dan juga akan memperbarui itu secara teratur dengan Capgo.
Saya berharap dapat menambahkan verifikasi pra-pembangunan yang lebih baik dari Capgo ke konfigurasi rilis semantik saya. bundle upload prasyarat
Saya telah memiliki alur rilis semantik yang bersih, sederhana, dan dapat diulang kembali 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 penawaran saya di Saya memiliki produk penawaran di Anda dapat menemukan saya di LinkedIn di
https://linkedin.com/in/rbarrow Anda dapat melihat penawaran Salesforce kami di .
https://www.rapido-companion.app Saya telah memiliki alur rilis semantik yang bersih, sederhana, dan dapat diulang kembali untuk aplikasi mobile masa depan yang dikembangkan dengan Ionic + Angular + __CAPGO_KEEP_0__. dan https://www.rapido.cloud (dalam pengembangan).
Teruskan dari Cara Rapido Cloud Mengelola Rilis Semantik dengan Capgo CapacitorUpdater
Jika Anda menggunakan Cara Rapido Cloud Mengelola Rilis Semantik dengan Capgo CapacitorUpdater untuk merencanakan pengiriman pembaruan hidup, hubungkannya dengan Capgo Live Updates for the product workflow in Capgo Live Updates, untuk detail implementasi di Overview, Ringkasan untuk detail implementasi di Ringkasan, untuk detail implementasi di Fitur Pengaturan Perbarui untuk detail implementasi di Pengaturan Perbarui, dan Jenis Perbarui untuk detail implementasi di Jenis Perbarui.
