Bagaimana Rapido Cloud mengelola Rilis Semantik dengan Capgo CapacitorUpdater

1. Pendahuluan

Di 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. Komponen-komponen ini lebih mudah untuk diatur 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 pengelola aplikasi seluler Ionic + Angular.

Artikel ini menjelaskan desain, pilihan dan implementasi saya yang membuat Capgo dan semantic-release sukses besar tanpa perlu berpikir keras untuk mengelola semua pengiriman 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 standar Apple AppStore/Google PlayStore.

Aplikasi seluler ini adalah aplikasi pertama saya yang saya kirim ke toko, karena saya sebelumnya lebih fokus pada aplikasi web, biasanya dikembangkan pada Salesforce Experience Cloud. Saya sangat takut dengan kurva belajar untuk membuat aplikasi ini sukses, tapi saya berhasil mengirim 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 memperbarui aplikasi saya di ponsel saya, secara langsung, 1 menit setelah menyimpan fitur baru atau perbaikan di sumber code : begitu menghibur, dan 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 :

• pengembangan dilakukan di feature/... cabang dari main, dan mereka diintegrasikan ke main yang merupakan acuan untuk sebagian besar cabang pengembangan, di luar perawatan dan fitur khusus untuk pengiriman kustom (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 diterima. Perbaikan akan membuat versi patch baru, sedangkan fitur akan membuat versi minor baru. Ini juga secara otomatis termasuk prelease alpha, beta, versi lainnya.

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.

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 lain-lain.

4. Cabang, rilis/prereleases, saluran dalam semantic release dan di Capgo

Jadi apa yang saya inginkan semantic release untuk melakukan pada Capgo adalah sebagai berikut.

Saya ingin semantic release menghasilkan nomor versi

Capgo telah mengembangkan dan mendokumentasikan versi mereka sendiri dari “Conventional Commits” standard-version alat, dengan repositori mereka yang diambil dari standard-version (https://github.com/Cap-go/standard-versiondan repositori 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 Versi Semantik ( semantic-release https://semver.org

) yang semantic-release juga mengikuti (tentu saja !) ,

Saya juga ingin semantic release menghasilkan pengiriman aplikasi pada saluran yang berbeda

Seperti 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 berikutnya 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 bundle 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 CI/CD pipeline Anda
• CAPGO_APPID disediakan oleh Capgo untuk mengidentifikasi unik aplikasi (misalnya com.mystartup.mysuperapp)

6. Pengaturan update Capacitor + Capgo semantic release

Akhirnya, bagaimana semua ini saling terkait?

Versi bundle aplikasi yang dibuat dengan semantic release dan Github Actions

Automasi release semantic dengan Github Actions

Keindahan dari release 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 release 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.

Karakteristik 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 terhubung ke saluran (name), mapped to the Capgo channel (channel). Misalnya, jikaprerelease, nomor versi yang dihasilkan oleh release otomatis akan menjadi branch.prerelease = "development"pengiriman ke x.y.z-development.n
  • dan alphadan alpha-nocapgo cabang akan mengdeploy aplikasi pada alphasaluran, tetapi dengan nama prerelease yang berbeda dalam nomor versi
  • pengiriman ke cabang pengembang dev-rupertatau dev-paul akan mengdeploy ke developmentsaluran pada Capgo, semua dengan kata kunci prerelease yang sama dalam nomor versi development: pada tahap pertama dari semantic release, 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-analyzer https://__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 perubahan berikut yang telah diperbarui oleh Ionic build dari aplikasi dan oleh pekerjaan semantic release ( CHANGELOG.md
• @semantic-release/git : mengirimkan berikut file yang telah diperbarui oleh Ionic build dari aplikasi dan oleh pekerjaan semantic release (package.json, CHANGELOG.md dan ios/App/App.xcodeproj/project.pbxproj - Saya tidak membangun untuk Android, belum)
• @semantic-release/github : lampirkan file ke rilis __CAPGO_KEEP_0__ sebagai aset CHANGELOG.md file 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 melihat bahwa tidak ada perlu menjelaskan bagaimana kita ingin versi nomor 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 ini (misalnya

• pada cabang ini, saya mengatur XCode Cloud untuk membangun hanya ketika file production)
• diupdate. Ini diupdate setelah setiap versi yang dihasilkan oleh semantic release CHANGELOG.md diupdate setelah setiap versi yang dihasilkan oleh semantic release
• Saya dapat memicu build pada cabang yang berbeda untuk meniru proses pengiriman untuk saluran yang berbeda. branch.channel Dalam setiap konfigurasi build XCode Cloud pada cabang yang berbeda, saya menetapkan variabel lingkungan secara manual dengan nilai dari releaserc.json Ditetapkan pada

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 trial, 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

Hal ini sesuai dengan build XCode Cloud dari 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 kemudian akan 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-bangun 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.