1. Pengenalan
Pada Rapido Cloud (www.rapido.cloud), saya sedang mengembangkan 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 harus dipikirkan lagi untuk mengelola semua pengiriman secara otomatis melalui Github Actions. Semua ini dirancang, diuji, dan dokumentasi selama periode percobaan gratis 14 hari dari Capgo CapacitorUpdater.
Mengapa menggunakan Capgo ? Mengapa menggunakan semantic-release ?
Capgo CapacitorUpdater attracted me with its promise to make mobile app deployments much more simple, much more rapid and flexible than going through the standard Apple AppStore/Google PlayStore delivery process. This is my first mobile application which I am pushing to the stores, having concentrated in the past on web apps, usually developed on the Salesforce Experience Cloud.
Karena saya baru pertama kali membuat aplikasi seluler, saya khawatir dengan kurva belajar untuk membuat ini sukses, tapi 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 mengupdate aplikasi saya di ponsel saya secara langsung, 1 menit setelah menyimpan fitur baru atau perbaikan di kode sumber code : sangat menghibur, dan fleksibel, dan mudah untuk diatur!
3. Model cabang dan rilis saya, dan bagaimana semantic-release berintegrasi
Sekarang saya telah mengirimkan aplikasi saya ke Capgo server dengan benar, saya perlu otomatisasi ini dan mengintegrasikannya ke dalam pipeline CI/CD saya.
Inilah cara saya mengatur model cabang dan rilis saya
Untuk setiap aplikasi, baik mobile, web atau Salesforce :
- pengembangan dilakukan pada
feature/...cabang yang berasal darimain, dan mereka diintegrasikan kemainyang merupakan acuan untuk sebagian besar cabang pengembangan, di luar perawatan dan fitur khusus untuk pengiriman khusus (lebih lanjut tentang ini di bawah) - pengiriman dilakukan dari cabang rilis yang mungkin :
production, cabang pralease (alpha,beta,nightly, dll.) dan juga cabang khusus pelanggan atau konteks untuk pengiriman khusus - Deploymen ini dipicu oleh permintaan pull. Namun, saya tidak menggunakan deploymen yang dipicu oleh tag karena semantic release mengelola tag dan semua hal lainnya untuk saya.
Secara singkat, ini adalah Gitlab Flow :
Gitlab Flow - sumber https://faun.dev/c/stories/manuelherrera/strategi-branching-git-di-tahun-2022
Catatan sampingan tentang bagaimana semantic-release bekerja :
Pada cabang deploymen, ketika semantic-release dipicu, maka akan secara otomatis menghitung nomor versi baru pada cabang ini, tergantung pada nomor versi sebelumnya pada 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 seperti yang ditentukan dalam komit konvensional (lihat https://www.conventionalcommits.org/en/about) dan dikonfigurasi dalam semantic release.
Selain itu, Capgo juga akan memperbarui semua permintaan pull yang telah diintegrasikan (Github, dalam kasus saya) dan masalah terkait dengan komentar yang menghubungkannya ke tag dan rilis. Akhirnya, dalam rilis ini Github, Capgo akan menambahkan aset seperti kode code, biner jika perlu, dll. CHANGELOG.md, dll.
4. Cabang, rilis/prereleases, saluran dalam rilis semantik dan di Capgo
Jadi apa yang saya inginkan rilis semantik untuk lakukan untuk Capgo adalah sebagai berikut.
Saya ingin rilis semantik menghasilkan nomor versi
Capgo telah mengembangkan dan mendokumentasikan versi mereka sendiri dari “Conventional Commits” standard-version alat, dengan fork repo mereka standard-version (https://github.com/Cap-go/versi-standardan versi mereka sendiri capacitor-standard-version (https://github.com/Cap-go/capacitor-versi-standar) as well as capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. They have documented on their blog the version scheme used by Capgo in their deployemnts (https://capgo.app/blog/cara-verifikasi-versi-di-capgoJavaScript bundle mengikuti "semver" versi "Semantic Versioning" standar.versi semver standar Versi Semantik semantic-release yang juga mengikuti (tentu saja !)
Jadi itu bagus, dan merupakan kelegaan bagi saya karena saya menggunakan semantic-release secara luas.
Saya juga ingin semantik release menghasilkan pengembangan aplikasi pada saluran yang berbeda
Seperti yang disebutkan di atas, saya perlu mengembangkan versi prerelease dari cabang seperti alpha, beta, nightly dan juga versi khusus pelanggan pada cabang seperti production-customer-jones, production-customer-doedan lain-lain.
Capgo menyediakan fitur “saluran” yang tepat apa yang juga didukung oleh rilis semantik, jadi saya sangat bersemangat untuk membuat mereka bekerja sama. Ini juga sesuai dengan berbagai jenis build branch yang dikelola oleh XCode Cloud (lihat lebih lanjut tentang ini di bawah).
Nomor versi semver yang dihasilkan oleh rilis semantik pada versi pra-rilis tampak seperti 1.0.0-alpha.1. Pembangunan berurutan pada cabang ini akan meningkatkan nomor pembangunan menjadi 1.0.0-alpha.2, 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 pra-rilis untuk menghasilkan versi aplikasi saya dengan saluran Capgo.
5. Bagaimana saya dapat menggunakan Capgo untuk merilis aplikasi saya?
Untuk mengautomatisasi pengiriman paket aplikasi Anda ke Capgo, Anda perlu menggunakan perintah Capgo CLI. bundle upload. Ketik npx @capgo/cli@latest bundle upload --help untuk mendapatkan banyak pilihan unggahan. Di antara pilihan tersebut, kita akan menggunakan:
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- SALURAN adalah saluran Capgo yang ingin kita unggah (misalnya
alpha) - VERSINYA dihasilkan oleh rilis semantik (misalnya
1.0.0-alpha.1) - APIKEY CAPGO disediakan oleh Capgo untuk mengidentifikasi unik login CI/CD Anda
- APPID CAPGO disediakan oleh Capgo untuk mengidentifikasi unik aplikasi Anda (misalnya
com.mystartup.mysuperapp)
6. Pengaturan rilis semantik saya + Capgo CapacitorUpdate
Jadi, bagaimana semua ini terintegrasi?
Paket aplikasi versi yang dibangun dengan rilis semantik dan Github Actions
Pengaturan otomatis rilis semantik dengan Github Actions
Keindahan rilis semantik adalah bahwa otomatisasi pengembangan, dalam bentuk alur kerja Github Actions, sangat sederhana. Ini akan terlihat sangat mirip pada platform CI/CD lainnya.
# ./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 rilis semantik.
Untuk setiap merge pada cabang yang terdaftar di branchesrilis semantik akan mengaktifkan pengembangan.
Atur CAPGO_APIKEY di rahasia repository Anda.
Perbarui CAPGO_APPID di sini.
Sikap perilaku rilis semantik ditetapkan di dalamnya .releaserc.json Konfigurasi file.
Berikut adalah pengaturan saya, dijelaskan di bawah ini :
// .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:branchesMengatur konfigurasi cabang (nameDitautkan ke saluran Capgo.channeldan bagaimana versi prarelease akan disebut (prereleaseContoh, jikabranch.prerelease = "development"Versi yang dihasilkan oleh semantic release akan menjadix.y.z-development.n- pengiriman ke
alphadanalpha-nocapgoCabang akan sama-sama mengdeploy aplikasi ke saluranalphatetapi dengan nama pralease yang berbeda dalam versi - Deploy ke cabang pengembang
dev-rupertataudev-paulakan mengirimkan kedua aplikasi kedevelopmentsaluran di Capgo, semua dengan yang samadevelopmentKata kunci pre-release dalam nomor versi
verifyConditions: Pada tahap pertama dari rilis semantik, sistem ini memeriksa apakah memiliki akses yang benar ke Github. Saya berharap dapat menambahkan pengecekan autentikasi untuk Capgo CLI di sini kemudian@semantic-release/commit-analyzer: Rilis semantik standar - lihat dokumentasi mereka (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#format-pesan-komit)@semantic-release/release-notes-generator: Membuat file perubahan sebagaiCHANGELOG.md@semantic-release/gitBerikut file yang telah diperbarui oleh Ionic build aplikasi dan pekerjaan semantic release ("package.json,CHANGELOG.mddanios/App/App.xcodeproj/project.pbxprojSaya tidak membangun untuk Android, (padahal)@semantic-release/github: Tidak membangun untuk Android, belumCHANGELOG.md: Mengikat file ke rilis Github sebagai aset@semantic-release/execGunakan 2 perintah ini untuk mempersiapkan pembangunan aplikasi.prepareCmd) dan kemudian untuk membangun dan mengdeploy bundle aplikasi ke server-server Capgo (publishCmd)
Anda akan melihat bahwa tidak ada perlu menjelaskan bagaimana kita ingin versi nomor dihitung dan ditingkatkan, bagaimana kita harus menghasilkan log perubahan, tag atau rilis Github, dll. : semuanya diatur secara default oleh semantic release, dengan konfigurasi minimal.
Pembangunan biner baru dengan XCode Cloud
Mengintegrasikan semua ini dengan XCode Cloud pembangunan versi baru dari biner aplikasi adalah sederhana (saya belum mengdeploy ke Google Play, tapi pembangunan itu seharusnya sama) :
- Saya mengatur proses XCode Cloud untuk membangun ketika ada perubahan pada cabang yang saya inginkan (misalnya)
production) - Pada cabang ini, saya mengatur XCode Cloud untuk membangun hanya ketika file
CHANGELOG.mddiupdate. Ini diupdate setelah setiap versi yang dihasilkan oleh semantic release - Saya dapat memicu pembangunan pada cabang-cabang yang berbeda untuk meniru penggunaan untuk saluran-saluran yang berbeda. Pada setiap konfigurasi pembangunan XCode Cloud pada cabang yang berbeda, saya mengatur variabel lingkungan secara manual dengan nilai dari
branch.channeldipasang direleaserc.json(ya, ini adalah duplikasi manual) dan kemudian, jika saya ingin, saya dapat mengdeploy aplikasi AppStore yang berbeda untuk setiap aplikasi pelanggan yang disesuaikan yang diambil dari cabang rilis yang disesuaikan, seperti yang disebutkan sebelumnya.
Membangun biner aplikasi di XCode Cloud dengan Capgo saluran
7. Kesimpulan
Secara keseluruhan, saya sangat senang telah dapat mengintegrasikan Capgo CapacitorUpdater ke dalam pipeline rilis semantik saya secara standar, 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 mengunduh bundle aplikasi Capgo, juga menggunakan Capgo saluran
- Hal ini sesuai dengan pembangunan XCode Cloud biner aplikasi
Next steps
Saya sedang dalam fase pengembangan aplikasi ini. Saya akan segera membuatnya tersedia untuk tester melalui TestFlight (untuk iOS). Mengingat kekuatan Capgo, saya pasti akan mengunduh versi gratis aplikasi ke AppStore untuk tes, yang akan diperbarui secara teratur dengan Capgo selama tes. Saya kemudian akan mengunduh versi lain (berbayar) aplikasi ke AppStore, di bawah catatan lain, dan juga memperbarui itu secara teratur dengan Capgo.
I hope to add better pre-build verification of Capgo bundle upload menambahkan persyaratan ke konfigurasi rilis semantik saya.
Saya memiliki sekarang aliran rilis semantik yang bersih, sederhana, dan dapat diulang untuk aplikasi mobile masa depan yang dikembangkan dengan Ionic + Angular + Capacitor.
Langkah selanjutnya
I telah memiliki pengalaman lebih dari 22 tahun di Salesforce, sebagai klien dan pengguna, sebagai mitra dan integrator, arsitek, pengembang, analis bisnis, dan konsultan. Saya co-founding dan co-manajemen Altius Services sebagai COO dan CTO selama 13 tahun, sebuah mitra SI Salesforce sukses di Perancis, sebelum memulai petualangan baru sebagai Salesforce solopreneur dengan produk saya Rapido Cloud produk penawaran.
Anda dapat menemukan saya di LinkedIn di linkedin.com/in/rbarrow.
Anda dapat melihat penawaran Salesforce kami di https://www.rapido-companion.app dan https://www.rapido.cloud (dalam pengembangan)
Teruskan dari Bagaimana Rapido Cloud mengelola Release Semantik dengan Capgo CapacitorUpdater
Jika Anda menggunakan How Rapido Cloud mengelola Rilis Semantik dengan Capgo CapacitorUpdater untuk merencanakan live update pengiriman, hubungkannya dengan Capgo Pembaruan Langsung untuk alur kerja produk di Capgo Live Updates, Ringkasan untuk detail implementasi di Ringkasan, Fitur untuk detail implementasi di Fitur, Perilaku Update untuk detail implementasi di Perilaku Update, dan Jenis Update Untuk detail implementasi dalam jenis Update.
