1. Pengenalan
Di Rapido Cloud (www.rapido.cloud), saya sedang mengembangkan sebuah aplikasi seluler untuk klien Salesforce agar dapat dengan mudah mengdeploy aplikasi seluler yang terbranding sendiri tanpa harus melewati proses 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. Komponen-komponen 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 pengelola aplikasi seluler Ionic + Angular.
Artikel ini menjelaskan desain, pilihan dan implementasi saya yang membuat Capgo dan semantic-release sukses tanpa harus berpikir keras untuk mengelola semua pengiriman secara otomatis melalui Github Actions. Semua ini dirancang, diuji dan dokumentasi selama periode percobaan gratis 14 hari dari Capgo CapacitorUpdater.
2. Mengapa menggunakan Capgo ? Mengapa menggunakan semantic-release ?
Capgo CapacitorUpdater menarik perhatian saya dengan janji untuk membuat pengiriman aplikasi seluler lebih mudah, lebih cepat dan lebih fleksibel daripada melewati proses standar Apple AppStore/Google PlayStore pengiriman.
Saya cukup takut dengan kurva pembelajaran untuk membuat ini sukses tapi saya berhasil menginstal aplikasi saya ke Apple TestFlight dengan mudah. Saya kemudian dalam posisi untuk menggunakan Capgo CapacitorUpdater untuk mengirimkan pembaruan 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 mengalir, begitu fleksibel, dan mudah untuk diatur !
3. Model cabang dan rilis saya, dan bagaimana semantic-release masuk ke dalamnya
Jadi sekarang saya memiliki pengiriman ke Capgo server bekerja 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 :
- dijalankan pada cabang dari
feature/..., 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)mainpengembangan - deployments diaktifkan oleh dari cabang rilis yang mungkin adalah :
production, cabang rilis pra-rilis (alpha,beta,nightly, dan lain-lain) serta juga cabang khusus pelanggan atau konteks untuk pengiriman khusus - deployments diaktifkan oleh permintaan pull yang sedang diintegrasikan ke cabang deployment. Saya tidak menggunakan pengaktifan cabang 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 tag sebelumnya pada cabang dan perbaikan atau fitur yang disampaikan. alpha, betaPerbaikan akan membuat versi patch baru, sedangkan fitur akan membuat versi minor baru.
Juga secara otomatis termasuk prerelease , dll. dalam nomor versi.Penerbitan semantik menghasilkan daftar perubahan dari komit Anda, mengelompokkan perbaikan dan fitur seperti yang ditentukan dalam komit konvensional (lihat
It will also update all your git (Github, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this Github release, it will attach assets such as source code, binaries if necessary, CHANGELOG.md) dan dikonfigurasi dalam penerbitan semantik.
Juga akan memperbarui semua pull request gabungan Anda (Capgo, dalam kasus saya) dan masalah terkait dengan komentar yang menghubungkannya ke tag dan rilis.
So what I want semantic release to do for Capgo deployments is the following.
, dll.
4. Cabang, rilis/prereleases, saluran dalam penerbitan semantik dan dalam Capgo standard-version Jadi apa yang saya inginkan penerbitan semantik untuk lakukan untuk __CAPGO_KEEP_0__ pengembangan adalah sebagai berikut. standard-version (https://github.com/Cap-go/versi-standar), dan versi mereka sendiri capacitor-standard-version (https://github.com/Cap-go/capacitor-versi-standar) termasuk repositori mereka sendiri. Mereka telah mendokumentasikan pada blog mereka tentang skema versi yang digunakan oleh __CAPGO_KEEP_0__ dalam penggunaan mereka ( capacitor-plugin-standard-version (https://github.app/blog/bagaimana-versi-bekerja-di-capacitor/) repos. They have documented on their blog the version scheme used by Capgo in their deployemnts (https://capgo.app/blog/how-version-work-in-capgo/semverSemantic Versioning(https://semver.org, ) yang semantic-release juga mengikuti (tentu saja !)
Jadi itu bagus, dan merupakan kelegaan bagi saya karena saya menggunakan semantic-release secara luas.
Saya juga ingin semantic release menghasilkan pengiriman aplikasi pada saluran yang berbeda.
Sebagaimana disebutkan di atas, saya membutuhkan untuk mengirimkan versi prerelease dari cabang seperti alpha, beta, nightly dan lain-lain, tetapi 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 semantic release, jadi saya sangat bersemangat untuk membuat mereka berinteraksi. 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 semantic release pada prereleases seperti 1.0.0-alpha.1Hasil bangun berikutnya pada cabang ini akan meningkatkan nomor bangun menjadi 1.0.0-alpha.2dan lain-lain. Meskipun tidak secara eksplisit dokumentasi, nomor versi ini didukung oleh Capgo, yang merupakan berita baik bagi saya : Saya akan menggunakan saluran semantic release dan prerelease untuk menghasilkan versi aplikasi saya dengan Capgo saluran.
5. Bagaimana saya dapat menggunakan Capgo untuk merilis aplikasi saya ?
Untuk mengautomatisasi pengiriman bundle aplikasi ke Capgo, Anda perlu menggunakan perintah Capgo CLI bundle upload. Tipe 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 mengirim (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. Pengaturan update Capacitor saya dengan semantic release + __CAPGO_KEEP_0__
Versi bundle aplikasi yang dibangun dengan semantic release dan Github Actions
Versi bundle aplikasi yang dibangun dengan semantic release dan Github Actions
Automasi rilis semantik 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 rilis semantik adalah bahwa otomatisasi pengiriman, dalam bentuk alur kerja __CAPGO_KEEP_0__ Actions, sangat sederhana. Ini akan terlihat sangat mirip pada platform CI/CD lainnya.
Untuk setiap mzerge pada cabang yang terdaftar di branches, rilis semantik akan memicu peluncuran.
Atur CAPGO_APIKEY dalam rahasia repository Anda.
Perbarui CAPGO_APPID di sini.
Sifat perilaku rilis semantik ditentukan dalam file konfigurasi. .releaserc.json Berikut adalah pengaturan saya, dijelaskan di bawah :
// .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:branchesmenetapkan pengaturan cabang (name), yang dikaitkan dengan saluran Capgo (channel) dan bagaimana nomor versi pra-rilis akan disebutkan (prerelease). Misalnya, jikabranch.prerelease = "development", nomor versi yang dihasilkan oleh rilis semantik akan menjadix.y.z-development.n- peluncuran ke
alphadanalpha-nocapgocabang akan mengirimkan aplikasi kealphasaluran, tetapi dengan nama prerelease yang berbeda dalam nomor versi - pengiriman ke cabang pengembang
dev-rupertataudev-paulakan mengirimkan kedevelopmentsaluran pada Capgo, semua dengan kata kunci prerelease yang sama dalam nomor versidevelopment: di tahap pertama dari semantic release, itu memeriksa bahwa memiliki akses yang benar ke __CAPGO_KEEP_0__. Saya berharap dapat menambahkan pengecekan autentikasi untuk __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ di sini kemudian
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-analyzerhttps://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formathttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator__CAPGO_KEEP_0__CHANGELOG.md@semantic-release/git: komit berikutnya file yang telah diperbarui oleh Ionic build aplikasi dan oleh pekerjaan semantic release (package.json,CHANGELOG.md: tambahkanios/App/App.xcodeproj/project.pbxprojfile ke rilis __CAPGO_KEEP_0__ sebagai aset@semantic-release/github: gunakan perintah-perintah ini untuk mempersiapkan pembangunan aplikasi (CHANGELOG.md) dan kemudian untuk membangun dan mengdeploy bundle aplikasi ke server Github (@semantic-release/execKamu akan melihat bahwa tidak ada fiddling untuk menjelaskan bagaimana kita ingin menghitung dan meningkatkan nomor versi, bagaimana kita harus menghasilkan log perubahan, tag atau rilis __CAPGO_KEEP_0__, dll. : semuanya diatur secara default oleh semantic release, dengan konfigurasi minimal.prepareCmd) and then to effectively build deploy the app bundle to the Capgo servers (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.
Saya mengatur proses XCode Cloud untuk membangun ketika ada perubahan pada cabang yang saya inginkan untuk digunakan (misalnya
pada cabang ini, saya mengatur XCode Cloud untuk membangun hanya ketika
- - Saya tidak membangun untuk Android, belum
production) - - Saya tidak membangun untuk Android, belum
CHANGELOG.mdfile diperbarui. Ini diperbarui setelah setiap versi yang dihasilkan oleh semantic release - Saya dapat memicu bangun pada cabang yang berbeda untuk meniru pengiriman untuk saluran yang berbeda. Pada setiap konfigurasi bangun XCode Cloud pada cabang yang berbeda, saya menetapkan variabel lingkungan secara manual dengan nilai dari
branch.channelditetapkan dalamreleaserc.json(ya, ini adalah duplikasi manual) dan kemudian, jika saya ingin, saya dapat mengirimkan aplikasi AppStore yang berbeda untuk setiap aplikasi klien yang disesuaikan yang dijalankan dari cabang rilis yang disesuaikan, seperti yang disebutkan sebelumnya.
Membangun biner aplikasi pada XCode Cloud dengan Capgo saluran
7. Kesimpulan
Dalam 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 diperbarui secara otomatis oleh semantic release dan kompatibel dengan Capgo server
- semantic release secara otomatis mengirimkan bundle aplikasi Capgo, juga menggunakan Capgo saluran
- ini sangat sesuai dengan bangun XCode Cloud dari biner aplikasi
Langkah-langkah selanjutnya
Saya sedang dalam fase pengembangan aplikasi ini. Aplikasi ini akan segera saya buat tersedia untuk tester melalui TestFlight (untuk iOS). Mengingat kekuatan Capgo, saya pasti akan mengeluarkan versi gratis aplikasi ini ke AppStore untuk tes, yang akan saya update secara teratur dengan Capgo selama tes. Kemudian saya akan mengeluarkan versi lain (berbayar) aplikasi ini di AppStore, di bawah catatan lain, dan juga saya akan update itu secara teratur dengan Capgo.
Saya berharap dapat menambahkan verifikasi pra-pembangunan yang lebih baik dari Capgo bundle upload prasyarat ke dalam konfigurasi rilis semantik saya.
Saya sekarang memiliki alur rilis semantik yang bersih, sederhana, dan dapat diulang untuk aplikasi mobile masa depan yang dikembangkan dengan Ionic + Angular + Capacitor.
Pengarang - Rupert Barrow
Saya memiliki pengalaman lebih dari 22 tahun di Salesforce, sebagai klien dan pengguna, sebagai mitra dan integrator, arsitek, pengembang, analis bisnis, dan konsultan. Saya bersama-sama 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. 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 akan segera membuat aplikasi ini tersedia untuk tester melalui TestFlight (untuk iOS). Mengingat kekuatan __CAPGO_KEEP_0__, saya pasti akan mengeluarkan versi gratis aplikasi ini ke AppStore untuk tes, yang akan saya update secara teratur dengan __CAPGO_KEEP_1__ selama tes. Kemudian saya akan mengeluarkan versi lain (berbayar) aplikasi ini di AppStore, di bawah catatan lain, dan juga saya akan update itu secara teratur dengan __CAPGO_KEEP_2__. Saya berharap dapat menambahkan verifikasi pra-pembangunan yang lebih baik dari __CAPGO_KEEP_0__ untuk prasyarat ke dalam konfigurasi rilis semantik saya. dan https://www.rapido.cloud (dalam pengembangan).
Teruskan dari Cara Rapido Cloud mengelola Semantic Release dengan Capgo CapacitorUpdater
Jika Anda menggunakan Cara Rapido Cloud mengelola Semantic Release dengan Capgo CapacitorUpdater untuk merencanakan pengiriman pembaruan hidup secara langsung, hubungkannya dengan Capgo Live Updates untuk alur kerja produk di Capgo Live Updates, Ringkasan untuk detail implementasi di Ringkasan, Fitur untuk detail implementasi di Fitur-Fitur, Perilaku Pembaruan untuk detail implementasi di Perilaku Pembaruan, dan Jenis Pembaruan untuk detail implementasi di Jenis Pembaruan.
