1. Pengenalan
Pada Rapido Cloud (www.rapido.cloud), saya sedang mengembangkan aplikasi seluler untuk klien Salesforce agar dapat dengan mudah mengdeploy aplikasi seluler yang dimiliki 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 aplikasi seluler Ionic + Angular.
Artikel ini menjelaskan desain, pilihan, dan implementasi saya yang membuat Capgo dan semantic-release sukses tanpa perlu 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 saya dengan janji untuk membuat proses pengiriman aplikasi seluler menjadi lebih sederhana, lebih cepat, dan lebih fleksibel daripada melalui proses standar Apple AppStore/Google PlayStore.
Ketika saya pertama kali menggunakan Capgo CapacitorUpdater, saya cukup takut dengan kurva belajar untuk membuat aplikasi ini sukses, tetapi saya berhasil mengirimkan aplikasi saya ke Apple TestFlight dengan mudah.
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 !
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, 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 cabang dan model 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 secara otomatis 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 ini dipicu oleh permintaan pull. Deploymen ini dipicu oleh pull request yang sedang diintegrasikan ke cabang deployment. Saya tidak menggunakan deploymen yang dipicu oleh tag karena semantic release mengelola tag dan semua yang lain untuk saya.
Secara singkat, 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 deployment, 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 disampaikan. 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.
It akan juga 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, itu akan menambahkan aset seperti sumber code, biner jika perlu, CHANGELOG.md, dll.
4. Cabang, rilis/prereleases, saluran dalam rilis semantik dan di Capgo
Jadi apa yang saya inginkan rilis semantik untuk melakukan 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/standard-version) dan versi mereka sendiri capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) serta 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/how-version-work-in-capgo/) yang mengikuti semver "Semantic Versioning" (https://semver.org) yang juga mengikuti (tentu saja !) semantic-release Jadi itu sangat bagus, dan merupakan kelegaan bagi saya karena saya menggunakan
secara luas. semantic-release 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
dan juga versi khusus pelanggan pada cabang seperti alpha, beta, nightly , dll. production-customer-jones, production-customer-doedll.
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 berbagai jenis build branch yang dikelola oleh XCode Cloud (lihat lebih lanjut di bawah).
Nomor versi semver yang dihasilkan oleh rilis semantik pada versi pra-rilis tampak seperti 1.0.0-alpha.1. Pembangunan berikutnya pada cabang ini akan meningkatkan nomor pembangunan menjadi 1.0.0-alpha.2, dst. Meskipun tidak secara eksplisit dokumentasi, nomor versi ini didukung oleh Capgo, yang merupakan berita baik bagi saya : saya akan menggunakan saluran rilis semantik dan versi 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 ke Capgo, Anda perlu menggunakan perintah Capgo CLI bundle upload. Tipe npx @capgo/cli@latest bundle upload --help untuk mendapatkan berbagai pilihan unggah. 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 (misal
alpha) - VERSINYA dihasilkan oleh rilis semantik (misal
1.0.0-alpha.1) - CAPGO_APIKEY disediakan oleh Capgo untuk mengidentifikasi unik login CI/CD Anda
- CAPGO_APPID disediakan oleh Capgo untuk mengidentifikasi unik aplikasi Anda (misal
com.mystartup.mysuperapp)
6. Pengaturan rilis semantik saya + Capgo CapacitorUpdate
Bagaimana semua ini terintegrasi?
Paket aplikasi versi yang dibangun dengan rilis semantik dan Github Actions
Automasi rilis semantik dengan Github Actions
Keindahan rilis semantik adalah bahwa otomatisasi pengiriman, dalam bentuk alur kerja Github Actions, 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 }}Hanya menginstal lingkungan NodeJS, kemudian memanggil rilis semantik.
Untuk setiap merge pada cabang yang terdaftar di branchesrilis semantik akan mengaktifkan pengiriman.
Atur CAPGO_APIKEY di rahasia repository Anda.
Perbarui CAPGO_APPID di sini.
context: Halaman/area: Situs web pemasaran Capgo. Peran: Kalimat situs web. Dilihat di: komponen harga/Faq.astro. Kunci pesan `di sini` (Di sini). .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:branchesmenetapkan konfigurasi cabang (name), mapped to the Capgo channel (channel) dan bagaimana nomor versi pra-rilis akan disebut (prerelease). Misalnya, jikabranch.prerelease = "development"nomor versi yang dihasilkan oleh semantic release akan menjadix.y.z-development.n- deploymen ke
alphadanalpha-nocapgocabang akan sama-sama mendeploymen aplikasi ke saluranalphatetapi dengan nama pra-rilis yang berbeda dalam nomor versi - deploymen ke cabang pengembang
dev-rupertataudev-paulakan mengirimkan kedua-duanya ke saluran pada __CAPGO_KEEP_0__, semua dengan kata kunci prerelease pada nomor versidevelopmentsaluran pada Capgo, semua dengan kata kunci prerelease pada nomor versidevelopmentprerelease pada nomor versi
verifyConditions: Pada tahap pertama dari rilis semantik, ia 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#commit-message-format)@semantic-release/release-notes-generator: Membuat file riwayat perubahan sebagaiCHANGELOG.md@semantic-release/git: Mengirimkan berikut file yang telah diperbarui oleh Ionic build aplikasi dan oleh pekerjaan rilis semantik (package.json,CHANGELOG.mddanios/App/App.xcodeproj/project.pbxprojcontext@semantic-release/githubdanCHANGELOG.mdfile to the Github release as an asset@semantic-release/exec: gunakan perintah-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 lagi perlu menjelaskan bagaimana cara menghitung dan meningkatkan versi aplikasi, bagaimana cara membuat log perubahan, tag atau rilis Github, dll. : semua itu diatur secara otomatis oleh semantic release dengan konfigurasi minimal.
Pembangunan biner baru dengan XCode Cloud
Mengintegrasikan semua ini dengan XCode Cloud untuk membangun versi baru dari aplikasi biner sangatlah mudah (saya belum mengdeploy ke Google Play, tetapi pembangunan untuk build tersebut 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 proses pengembangan 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.channelyang ditetapkan padareleaserc.json(ya, ini adalah duplikasi manual) dan kemudian, jika saya ingin, saya dapat mengdeploy aplikasi AppStore yang berbeda untuk setiap aplikasi klien 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 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 secara otomatis mengunggah Capgo bundle aplikasi, juga menggunakan Capgo saluran
- Hal ini sesuai dengan pembangunan awan XCode dari biner aplikasi
Langkah selanjutnya
Saya sedang dalam fase pengembangan aplikasi ini. Saya akan segera membuatnya tersedia bagi tester melalui TestFlight (untuk iOS). Mengingat kekuatan Capgo, saya pasti akan mengunggah versi gratis aplikasi ke AppStore untuk tes, yang akan diperbarui secara teratur dengan Capgo selama tes. Saya kemudian akan mengunggah versi lain (berbayar) aplikasi ke AppStore, di bawah catatan lain, dan juga memperbarui itu secara teratur dengan Capgo.
Saya berharap dapat menambahkan verifikasi pra-pembangunan yang lebih baik dari Capgo ke dalam konfigurasi rilis semantik saya. bundle upload Saya telah memiliki pipeline rilis semantik yang bersih, sederhana, dan dapat diulang untuk aplikasi mobile masa depan yang dikembangkan dengan Ionic + Angular + __CAPGO_KEEP_0__.
I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.
Membangun aplikasi di XCode Cloud dengan __CAPGO_KEEP_0__ saluran
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-managing 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 Temukan saya di LinkedIn di
https://linkedin.com/in/rbarrow Temukan 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_KEEP_0__ CapacitorUpdater
Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater
protectedTokens How Rapido Cloud mengelola Rilis Semantik dengan Capgo CapacitorUpdater untuk merencanakan pengiriman update 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 Sikap Update untuk detail implementasi di Sikap Update, dan Jenis Update __CAPGO_KEEP_0__ CapacitorUpdater
