1. Pendahuluan
Di Rapido Cloud (www.rapido.cloud), saya mengembangkan aplikasi mobile untuk klien Salesforce agar mereka dapat dengan mudah mendeploy aplikasi mobile berbranding mereka sendiri tanpa harus melewati proses rumit menggunakan Salesforce Mobile SDK atau Salesforce Mobile Publisher.
Saya mengembangkan aplikasi mobile ini di platform modern dan “standar” dengan komponen dan tools yang luas, termasuk Ionic 8, Angular 18, TypeScript, Capacitor, dan sekarang Capgo CapacitorUpdater. Ini lebih mudah ditangani bagi klien yang tidak ingin mengelola spesifikasi platform Salesforce seperti Lightning Web Components; dan lebih mudah serta murah bagi saya untuk merekrut developer dan maintainer aplikasi mobile Ionic + Angular.
Artikel ini menjelaskan desain, pilihan, dan implementasi saya yang membuat Capgo dan semantic-release menjadi solusi yang sangat sukses dan tanpa keraguan untuk mengelola semua deployment secara otomatis via Github Actions. Semua ini dirancang, diuji, dan didokumentasikan selama masa uji coba gratis 14 hari yang menyenangkan dari Capgo CapacitorUpdater.
2. Mengapa menggunakan Capgo? Mengapa menggunakan semantic-release?
Capgo CapacitorUpdater menarik saya dengan janji untuk membuat deployment aplikasi mobile jauh lebih sederhana, cepat, dan fleksibel dibandingkan proses distribusi standar melalui Apple AppStore/Google PlayStore. Ini adalah aplikasi mobile pertama saya yang saya terbitkan ke toko, setelah sebelumnya fokus pada web app, yang biasanya dikembangkan di Salesforce Experience Cloud.
Saya agak khawatir dengan kurva belajarnya untuk berhasil, tetapi saya berhasil mengunggah aplikasi saya ke Apple TestFlight dengan cukup mudah. Setelah itu, saya siap menggunakan Capgo CapacitorUpdater untuk mendeploy update saya jauh lebih cepat.
Kebutuhan dan test case pertama saya adalah melakukan deploy untuk diri sendiri agar bisa menguji aplikasi saya sebagai aplikasi mobile asli di HP saya sendiri, alih-alih menguji di emulator mobile atau simulator melalui browser mobile Nexus yang disarankan Ionic. Itu karena aplikasi saya memakai fitur native seperti Geolocation atau mengakses Galeri Foto dan Kamera. Karena belum punya pengalaman menguji Capacitor mobile app, saya tidak yakin semuanya akan berjalan dengan benar: tidak ada yang lebih baik daripada menguji aplikasi aslinya, dalam kondisi nyata!
Jadi Capgo CapacitorUpdater membantu saya memperbarui aplikasi di HP saya secara live, hanya 1 menit setelah menyimpan fitur atau perbaikan baru di source code saya: sangat melegakan, fleksibel, dan mudah diatur!
3. Model branching dan release saya, serta bagaimana semantic-release berperan
Sekarang setelah pengiriman ke server Capgo saya berjalan dengan benar, saya perlu mengotomatisasi ini dan memasukkannya ke dalam pipeline CI/CD saya.
Beginilah cara saya mengatur model branching dan release saya
Untuk setiap aplikasi, baik mobile, web, maupun Salesforce:
- development dilakukan pada
feature/...branch darimain, dan di-merge ke dalammainyang menjadi acuan untuk sebagian besar branch development, di luar maintenance dan fitur khusus untuk custom delivery (selengkapnya di bawah) - deployments dipicu dari branch release yang bisa berupa:
production, branch prerelease (alpha,beta,nightly, dll.) serta branch khusus pelanggan atau konteks tertentu untuk pengiriman custom - deployment dipicu oleh pull request yang di-merge ke deployment branch. Saya tidak menggunakan deployment berbasis tag karena semantic-release sudah mengelola tag dan semuanya untuk saya.
Pada dasarnya, ini adalah Gitlab Flow:
Gitlab Flow - sumber https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Catatan tambahan tentang cara kerja semantic-release:
Di deployment branch, saat semantic-release dipicu, ia otomatis menghitung nomor versi baru di branch tersebut, berdasarkan nomor versi tag sebelumnya di branch itu serta fix atau fitur yang dikirim. Fix akan menghasilkan patch version baru, sedangkan fitur menghasilkan minor version baru. Ini juga otomatis menyertakan prerelease alpha, beta, dll. di nomor versi.
Semantic release membuat changelog dari commit Anda, mengelompokkan perbaikan dan fitur sesuai definisi conventional commits (lihat https://www.conventionalcommits.org/en/about) dan dikonfigurasi di semantic release.
Ini juga akan memperbarui semua git pull request yang sudah di-merge (Github, dalam kasus saya) dan issue terkait dengan komentar yang menghubungkannya ke tag dan release. Terakhir, pada release Github ini, ia akan melampirkan aset seperti source code, binary jika diperlukan, CHANGELOG.md, dll.
4. Branches, releases/prereleases, channels di semantic release dan di Capgo
Jadi, inilah yang saya ingin semantic release lakukan untuk deployment Capgo.
Saya ingin semantic release membuat nomor versi
Capgo telah mengembangkan dan mendokumentasikan versi “Conventional Commits” mereka sendiri standard-version tool, dengan repo fork mereka standard-version (https://github.com/Cap-go/standard-version), dan milik mereka sendiri capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) as well as capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. Mereka mendokumentasikan skema versi yang digunakan oleh Capgo di deployment mereka di blog (https://capgo.app/blog/how-version-work-in-capgo/). Bundle JavaScript mengikuti “standar” semver “Semantic Versioning” (https://semver.org) yang semantic-release juga mengikutinya (tentu saja!)
Jadi itu bagus, dan melegakan bagi saya karena saya menggunakan semantic-release secara luas.
Saya juga ingin semantic release menghasilkan deployment aplikasi di channel yang berbeda
Seperti disebutkan di atas, saya perlu mendeploy versi prerelease dari branch seperti alpha, beta, nightly dll., tetapi juga versi khusus pelanggan di branch seperti production-customer-jones, production-customer-doe, dll.
Capgo menyediakan fitur “channels” yang persis didukung oleh semantic release, jadi saya antusias untuk membuat keduanya bekerja sama. Hal ini juga selaras dengan build cabang berbeda yang dikelola oleh XCode Cloud (lihat lebih lanjut di bawah).
Nomor versi semver yang dihasilkan oleh semantic release pada prerelease terlihat seperti 1.0.0-alpha.1. Build berurutan pada cabang ini akan meningkatkan nomor build menjadi 1.0.0-alpha.2, dst. Meskipun tidak didokumentasikan secara eksplisit, nomor versi ini didukung oleh Capgo, yang merupakan kabar baik bagi saya: saya akan menggunakan channel dan prerelease dari semantic release untuk menghasilkan versi aplikasi saya dengan channel Capgo.
5. Bagaimana cara menggunakan Capgo untuk merilis aplikasi saya?
Untuk mengotomasi deployment bundle aplikasi Anda ke Capgo, Anda perlu menggunakan perintah Capgo CLI bundle upload. Ketik npx @capgo/cli@latest bundle upload --help untuk mendapatkan berbagai opsi upload. Di antaranya, kami akan menggunakan yang berikut:
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL adalah channel Capgo yang ingin kita deploy (mis.
alpha) - VERSION dihasilkan oleh semantic release (mis.
1.0.0-alpha.1) - CAPGO_APIKEY disediakan oleh Capgo untuk mengidentifikasi secara unik login pipeline CI/CD Anda
- CAPGO_APPID disediakan oleh Capgo untuk mengidentifikasi secara unik aplikasi Anda (mis.
com.mystartup.mysuperapp)
6. Setup semantic release + Capgo CapacitorUpdate saya
Terakhir, bagaimana semua ini menyatu?
Versi bundle aplikasi yang dibangun dengan semantic release dan Github Actions
Otomatisasi semantic release dengan Github Actions
Keindahan semantic release adalah otomasi deployment, dalam bentuk workflow Github Action, sangat sederhana. Ini akan terlihat sangat mirip di 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, lalu memanggil semantic release.
Untuk setiap merge pada branch yang terdaftar di branches, semantic release akan memicu deployment.
Setel CAPGO_APIKEY di secrets repositori Anda.
Perbarui CAPGO_APPID di sini.
Perilaku semantic release diatur di .releaserc.json file konfigurasi.
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 branch (name), yang dipetakan ke channel Capgo (channel) dan bagaimana nomor versi prerelease akan dipanggil (prerelease). Misalnya, jikabranch.prerelease = "development", nomor versi yang dihasilkan oleh semantic release akan menjadix.y.z-development.n- deployments ke
alphadanalpha-nocapgokedua branch akan men-deploy app kealphachannel, tapi dengan nama prerelease berbeda pada nomor versi - deployment ke developer branch
dev-rupertataudev-paulkeduanya akan men-deploy kedevelopmentchannel di Capgo, semuanya dengandevelopmentkeyword prerelease yang sama pada nomor versi
verifyConditions: pada tahap pertama semantic release, ia memastikan akses ke Github sudah benar. Saya berharap nanti bisa menambahkan pengecekan autentikasi untuk Capgo CLI di sini@semantic-release/commit-analyzer: hal standar semantic release - lihat dokumentasinya (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: men-generate file changelog sebagaiCHANGELOG.md@semantic-release/git: commit file berikut yang sudah diupdate oleh build Ionic aplikasi dan proses semantic release (package.json,CHANGELOG.mddanios/App/App.xcodeproj/project.pbxproj- Saya belum build untuk Android, untuk saat ini)@semantic-release/github: lampirkanCHANGELOG.mdfile ke rilis Github sebagai asset@semantic-release/exec: gunakan 2 perintah ini untuk menyiapkan build aplikasi (prepareCmd) lalu untuk benar-benar build dan deploy bundle aplikasi ke server Capgo (publishCmd)
Anda akan perhatikan bahwa tidak perlu repot menjelaskan bagaimana nomor versi dihitung dan ditingkatkan, bagaimana changelog, tag Github, atau release perlu dibuat, dll. : semuanya ditangani secara default oleh semantic release, dengan konfigurasi minimal.
Membangun binary baru dengan XCode Cloud
Mengintegrasikan semua ini dengan XCode Cloud untuk membangun versi baru binary aplikasi itu sederhana (saya belum deploy ke Google Play, tapi build-nya seharusnya serupa) :
- Saya mengatur proses XCode Cloud untuk build saat ada perubahan di branch yang ingin saya gunakan untuk ini (mis
production) - pada branch ini, saya mengatur XCode Cloud untuk build hanya ketika
CHANGELOG.mdfile diperbarui. File ini diperbarui setelah setiap versi yang dihasilkan oleh semantic release - Saya bisa memicu build di berbagai branch untuk mensimulasikan deployment ke channel yang berbeda. Di setiap konfigurasi build XCode Cloud pada branch yang berbeda, saya mengatur environment variable secara manual dengan nilai
branch.channelyang diatur direleaserc.json(ya, ini duplikasi manual) lalu, kalau mau, saya bisa men-deploy aplikasi AppStore yang berbeda untuk setiap aplikasi customer kustom yang di-deploy dari release branch kustom, seperti yang disebutkan sebelumnya.
Build binary aplikasi di XCode Cloud dengan channel Capgo
7. Kesimpulan
Kesimpulannya, saya sangat senang bisa mengintegrasikan Capgo CapacitorUpdater ke pipeline semantic release standar saya, dengan sangat cepat dalam rentang masa trial 14 hari, dan hasilnya adalah:
- nomor versi bundle dibuat otomatis oleh semantic release dan kompatibel dengan server Capgo
- semantic release otomatis men-deploy bundle aplikasi Capgo, sekaligus memanfaatkan channel Capgo
- ini sangat cocok dengan build binary aplikasi di XCode Cloud
Langkah berikutnya
Saat ini saya sedang dalam fase pengembangan aplikasi ini. Saya akan segera menyediakannya untuk tester melalui TestFlight (untuk iOS). Mengingat kekuatan Capgo, saya pasti akan men-deploy versi gratis aplikasi ke AppStore untuk pengujian, yang akan di-update secara rutin dengan Capgo selama pengujian. Setelah itu, saya akan men-deploy versi lain (berbayar) di AppStore di bawah record berbeda, dan juga meng-update-nya secara rutin dengan Capgo.
I hope to add better pre-build verification of Capgo bundle upload sebagai prasyarat dalam konfigurasi semantic release saya.
Sekarang saya punya pipeline semantic release yang bersih, sederhana, dan dapat direproduksi untuk aplikasi mobile masa depan yang dikembangkan dengan Ionic + Angular + Capacitor.
Penulis - Rupert Barrow
Saya memiliki pengalaman lebih dari 22 tahun di Salesforce, baik sebagai klien dan pengguna, maupun sebagai partner dan integrator, arsitek, developer, business analyst, dan konsultan. Saya ikut mendirikan dan mengelola Altius Services sebagai COO dan CTO selama 13 tahun, sebuah partner SI Salesforce yang sukses di Prancis, sebelum memulai petualangan baru sebagai solopreneur Salesforce dengan Rapido Cloud produk kami.
Anda bisa menemukan saya di LinkedIn di https://linkedin.com/in/rbarrow.
Anda bisa melihat penawaran Salesforce kami di https://www.rapido-companion.app dan https://www.rapido.cloud (sedang dikembangkan).
Lanjut ke Bagaimana Rapido Cloud mengelola Semantic Release dengan Capgo CapacitorUpdater
Jika Anda menggunakan Cara Rapido Cloud mengelola Semantic Release dengan Capgo CapacitorUpdater untuk merencanakan pengiriman live update, hubungkan dengan Live Updates Capgo untuk alur kerja produk di Capgo Live Updates, Ikhtisar untuk detail implementasi di Overview, Fitur untuk detail implementasi di Features, Perilaku Update untuk detail implementasi di Update Behavior, dan Tipe Update untuk detail implementasi di Update Types.
