1. Pendahuluan
Di Rapido Cloud (www.rapido.cloud), saya sedang mengembangkan aplikasi mobile untuk klien Salesforce agar dapat dengan mudah mengdeploy aplikasi mobile yang terbranding sendiri tanpa harus melewati loop yang sulit menggunakan Salesforce Mobile SDK atau Salesforce Mobile Publisher.
I 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 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 suatu keputusan yang sangat mudah untuk mengelola semua pengiriman secara 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 proses pengiriman aplikasi seluler menjadi lebih sederhana, lebih cepat dan lebih fleksibel daripada proses pengiriman standar melalui Apple AppStore/Google PlayStore.
I was rather afraid of the learning curve to make this successful but I got my app onto Apple TestFlight quite easily. I was then in position to use Capgo CapacitorUpdater to deploy my updates much faster.
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 lega, dan begitu fleksibel, dan mudah untuk diatur !
3. Model cabang dan rilis saya, dan bagaimana semantic-release berada di dalamnya
Sekarang saya sudah memiliki pengiriman ke Capgo server yang berfungsi dengan baik, 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 diadakan pada
feature/...cabang 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 diaktifkan dari cabang rilis yang mungkin adalah :
production, cabang rilis pra-rilis (alpha,beta,nightly, dan juga cabang khusus pelanggan atau konteks untuk pengiriman khusus - pengiriman diaktifkan oleh permintaan pull 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 :
Pada cabang pengiriman, ketika semantic-release diaktifkan, maka akan secara otomatis menghitung nomor versi baru pada cabang ini, tergantung pada nomor versi sebelumnya pada 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, betaVersi nomor, dll.
Semantic release menghasilkan daftar perubahan dari komit Anda, mengelompokkan perbaikan dan fitur sesuai dengan konvensi komit (lihat https://www.conventionalcommits.org/en/about) dan dikonfigurasi dalam semantic release.
Selain itu, semantic release juga akan memperbarui semua pull request (Github, misalnya) dan masalah terkait dengan komentar yang menghubungkannya ke tag dan rilis. Akhirnya, dalam rilis ini (Github), semantic release akan menambahkan aset seperti sumber code, biner jika perlu, dll. CHANGELOG.md4. Cabang, rilis/prereleases, saluran dalam semantic release dan dalam __CAPGO_KEEP_0__
Jadi apa yang saya inginkan semantic release untuk lakukan pada Capgo adalah sebagai berikut.
Saya ingin semantic release menghasilkan nomor versi Capgo
__CAPGO_KEEP_0__ telah mengembangkan dan mendokumentasikan versi mereka sendiri dari “Conventional Commits”
Capgo have developed and documented their own version of the “Conventional Commits” standard-version https://__CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (githubdan versi mereka sendiri capacitor-standard-version (https://github.com/Cap-go/capacitor-versi-standar) juga capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standar-versi) repositori. Mereka telah mendokumentasikan skema versi yang digunakan oleh Capgo dalam blog mereka (https://capgo.app/blog/cara-versi-bekerja-di-capgo/). Bundel JavaScript mengikuti semver "Semantic Versioning" (https://semver.org) yang juga mengikuti (tentu saja !) semantic-release Jadi itu bagus, dan merupakan kelegaan bagi saya karena saya menggunakan
secara luas. semantic-release __CAPGO_KEEP_0__
I juga ingin semantic release menghasilkan pengiriman aplikasi pada saluran yang berbeda
As yang disebutkan di atas, saya perlu mengirimkan versi prerelease dari cabang seperti alpha, beta, nightly dan juga versi khusus pelanggan pada cabang seperti production-customer-jones, production-customer-doe, dll.
Capgo menyediakan fitur “saluran” yang tepat apa yang juga didukung oleh semantic release, jadi saya sangat bersemangat untuk membuat mereka bekerja sama. Fitur ini juga sesuai dengan pengiriman cabang 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.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 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 bundel aplikasi ke Capgo, Anda perlu menggunakan perintah Capgo CLI bundle upload. Tipe npx @capgo/cli@latest bundle upload --help 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 saluran Capgo ke mana kita ingin mengdeploy (misalnya
alpha) - VERSION dibuat oleh semantic release (misalnya
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 unik aplikasi (misalnya
com.mystartup.mysuperapp)
6. Pengaturan update Capacitor + Capgo
Akhirnya, bagaimana semua ini terintegrasi?
Versi bundle aplikasi yang dibuat dengan semantic release dan Github Actions
Automasi rilis semantic dengan Github Actions
Keindahan dari rilis semantic 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 }}Hanya menginstal lingkungan NodeJS, kemudian memanggil rilis semantic.
Untuk setiap mzerge pada cabang yang terdaftar di branchesrelease otomatis akan memicu pengiriman.
Atur CAPGO_APIKEY dalam rahasia repositori Anda.
Perbarui CAPGO_APPID di sini.
Karena perilaku release otomatis ditentukan dalam file konfigurasi-nya.
Berikut adalah pengaturan saya, dijelaskan di bawah ini : .releaserc.json menentukan konfigurasi 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 diterjemahkan ke saluran __CAPGO_KEEP_0__ (name), mapped to the Capgo channel (channel). Misalnya, jikaprerelease, versi yang dihasilkan oleh release otomatis akan menjadibranch.prerelease = "development"pengiriman kex.y.z-development.n- dan
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: dalam tahap pertama dari rilis semantik, itu memeriksa bahwa memiliki akses yang benar ke __CAPGO_KEEP_0__. Saya berharap untuk 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: mengirimkan berikut file yang telah diperbarui oleh Ionic build dari aplikasi dan oleh pekerjaan rilis semantik (CHANGELOG.md@semantic-release/gitapplication dan oleh pekerjaan rilis semantik (package.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__ (prepareCmdAnda akan menyadari bahwa tidak ada perlu menjelaskan bagaimana kita ingin versi nomor untuk dihitung dan ditingkatkan, bagaimana kita harus menghasilkan log perubahan, 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 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 untuk digunakan (misalnya
- Pada cabang ini, saya atur XCode Cloud untuk membangun hanya ketika file
production) - diupdate. Ini diupdate setelah setiap versi yang dihasilkan oleh semantic release
CHANGELOG.mddiupdate setelah setiap versi yang dihasilkan oleh semantic release - Saya dapat memicu bangunan pada cabang yang berbeda untuk meniru pengiriman untuk saluran yang berbeda.
branch.channelDalam setiap konfigurasi bangunan XCode Cloud pada cabang yang berbeda, saya menetapkan variabel lingkungan secara manual dengan nilaireleaserc.jsondipasang di
Membangun biner aplikasi pada XCode Cloud dengan Capgo saluran
Membangun biner aplikasi pada XCode Cloud dengan __CAPGO_KEEP_0__ saluran
In conclusion, I am very happy to have been able to integrate Capgo CapacitorUpdater into my standard semantic release pipeline, rapidly within the delay of the 14-day trial period, and the result is the following :
- 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 :
- semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
- rilis semantik secara otomatis mengirimkan bundle aplikasi __CAPGO_KEEP_0__, juga menggunakan __CAPGO_KEEP_1__ saluran
ini sangat sesuai dengan bangunan XCode Cloud biner aplikasi
Langkah selanjutnya yang akan saya lakukan adalah mengembangkan aplikasi ini lebih lanjut. Saya akan segera membuatnya tersedia bagi 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 yang berbeda, dan juga memperbarui itu secara teratur dengan Capgo.
Saya berharap dapat menambahkan verifikasi pra-build yang lebih baik untuk 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 lebih dari 22 tahun pengalaman dengan 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 saya. Rapido Cloud Produk 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 dan https://www.rapido.cloud Sedang 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, 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 Perilaku Update untuk detail implementasi di Perilaku Update, dan Jenis Update untuk detail implementasi di Jenis Update.
