How Rapido Cloud mengelola Capgo Semantik Release dengan CapacitorUpdater

1. Pengenalan

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

Saya telah mengembangkan aplikasi mobile 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 aplikasi mobile Ionic + Angular.

Artikel ini menjelaskan desain, pilihan, dan implementasi saya yang membuat Capgo semantic-release a very successful no-brainer for managing all deployments automatically via Github Actions. All this was designed, tested and documented during the nice 14-day free trial period of 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.

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.

Saya sangat takut dengan kurva belajar untuk membuat ini sukses, tapi saya berhasil mengirimkan aplikasi saya ke Apple TestFlight dengan mudah. Saya kemudian dapat menggunakan Capacitor CapacitorUpdater untuk mengirimkan update saya lebih cepat.

So Capgo CapacitorUpdater helped me update my application on my mobile, live, 1 minute after saving a new feature or fix in my source code : so relieving, and so flexible, and easy to set up !

3. Model cabang dan rilis saya, dan bagaimana semantic-release berada di dalamnya

Sekarang saya memiliki pengiriman ke Capgo server saya berjalan 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 di lakukan 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 khusus (lebih lanjut tentang ini di bawah)
• pengiriman diaktifkan dari cabang rilis yang mungkin adalah : production, cabang pre-release (alpha, beta, nightly, dll.) dan juga cabang khusus pelanggan atau konteks untuk pengiriman khusus
• pengiriman diterbitkan oleh permintaan pull sedang diintegrasikan ke cabang pengiriman. Saya tidak menggunakan pengiriman yang dipicu 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 diberikan. Perbaikan akan membuat versi patch baru, sedangkan fitur akan membuat versi minor baru. Selain itu, juga secara otomatis termasuk alpha, beta, dll. dalam nomor versi.

Semantic release menghasilkan daftar perubahan dari komit Anda, mengelompokkan perbaikan dan fitur sesuai dengan definisi komit konvensional (lihat https://www.conventionalcommits.org/en/about) dan dikonfigurasi dalam semantic release.

It juga akan memperbarui semua pull request yang sudah 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 semantic release dan dalam Capgo

Jadi apa yang saya inginkan semantic release untuk melakukan untuk 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 di- standard-version (https://github.com/Cap-go/standard-version) dan versi mereka sendiri capacitor-standard-version (https://github.com/Cap-go/capacitor-versi-standar) termasuk juga capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standar-versi) repositori mereka. Mereka telah mendokumentasikan skema versi yang digunakan oleh Capgo dalam penggunaan mereka (https://capgo.app/blog/cara-versi-digunakan-di-capgo/). Bundel JavaScript mengikuti versi semver Semantic Versioning, semantic-release https://semver.org

) yang juga mengikuti (tentu saja !) semantic-release Jadi itu sangat bagus, dan merupakan kelegaan bagi saya karena saya menggunakan

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

As disebutkan di atas, saya perlu menginstal versi pra-rilis 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 membuatnya berjalan bersama. Fitur ini juga sesuai dengan berbagai jenis bangunan cabang yang diatur oleh XCode Cloud (lihat lebih lanjut tentang ini di bawah).

Nomor versi semver yang dihasilkan oleh semantic release pada pra-rilis seperti 1.0.0-alpha.1. Bangunan-bangunan berikutnya pada cabang ini akan meningkatkan nomor bangunan menjadi 1.0.0-alpha.2, dll. Meskipun tidak secara eksplisit dokumentasi, nomor-nomor versi ini didukung oleh Capgo, yang merupakan berita baik bagi saya : saya akan menggunakan saluran semantic release dan pra-rilis untuk menghasilkan versi aplikasi saya dengan Capgo saluran.

5. Bagaimana saya dapat menggunakan Capgo untuk merilis aplikasi saya ?

Untuk mengautomatisasi penginstalan 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-pilihan tersebut, kami akan menggunakan :

npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID

• SALURAN adalah saluran Capgo ke mana kami ingin mengunggah (misalnya alpha)
• Versi adalah dihasilkan oleh rilis semantik (misal 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 (misal com.mystartup.mysuperapp)

6. Rilis semantik + Capgo Pengaturan CapacitorUpdate

Terakhir, bagaimana semua ini terintegrasi?

Versi bundle aplikasi yang dibangun dengan rilis semantik dan Github Aksi

Automasi rilis semantik dengan Github Aksi

Keindahan rilis semantik adalah bahwa otomatisasi pengiriman, dalam bentuk alur kerja Github Aksi, sangat sederhana. Ini akan terlihat sangat mirip pada 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 mzerge pada cabang yang terdaftar dalam branches, rilis semantik akan memicu pengiriman. Tetapkan CAPGO_APIKEY di rahasia repositori Anda. Perbarui CAPGO_APPID di sini.

Kebijakan perilaku dari semantic release ditentukan dalam file konfigurasi-nya. Berikut adalah pengaturan saya, dijelaskan di bawah ini : .releaserc.json menentukan pengaturan 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 (name), mapped to the Capgo channel (channel). Misalnya, jikaprerelease, nomor versi yang dihasilkan oleh semantic release akan menjadi branch.prerelease = "development", the version number generated by semantic release will be x.y.z-development.n
  • deploymen ke alphadan alpha-nocapgo cabang akan sama-sama mendeploykan aplikasi ke alphasaluran, tetapi dengan nama prerelease yang berbeda dalam nomor versi
  • deploymen ke cabang pengembang dev-rupertatau dev-paul akan berdua deploy ke developmentsaluran pada Capgo, semua dengan kata kunci prerelease yang sama dalam nomor versi development: di 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 berikut file yang telah diperbarui oleh Ionic build dari aplikasi dan oleh pekerjaan semantic release ( CHANGELOG.md
• @semantic-release/git danpackage.json, CHANGELOG.md dan ios/App/App.xcodeproj/project.pbxproj - Saya tidak membangun untuk Android, padahal)
• @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 fiddling sekitar menjelaskan bagaimana kita ingin versi nomor untuk dihitung dan ditingkatkan, bagaimana kita perlu menghasilkan log perubahan, tag Capgo atau rilis, 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 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

• Saya mengatur XCode Cloud untuk membangun hanya ketika file production)
• diupdate. Ini diupdate setelah setiap versi yang dihasilkan oleh semantic release CHANGELOG.md Saya dapat memicu pembangunan pada cabang yang berbeda untuk meniru pengiriman untuk saluran yang berbeda. Pada setiap konfigurasi pembangunan XCode Cloud pada cabang yang berbeda, saya mengatur variabel lingkungan secara manual dengan nilai dari
• __CAPGO_KEEP_0__ branch.channel dipasang di releaserc.json (ya, ini adalah duplikasi manual) dan kemudian, jika saya ingin, saya bisa menginstal aplikasi AppStore yang berbeda untuk setiap aplikasi klien yang diinstal dari cabang rilis kustom, seperti yang disebutkan sebelumnya.

Membangun biner aplikasi di XCode Cloud dengan Capgo saluran.

7. Kesimpulan

Dalam kesimpulan, saya sangat senang telah dapat mengintegrasikan Capgo CapacitorUpdater ke dalam pipeline rilis semantik saya secara standar, dengan cepat dalam jangka waktu 14 hari trial, dan hasilnya adalah sebagai berikut :

• nomor versi bundle dihasilkan secara otomatis oleh rilis semantik dan kompatibel dengan Capgo server.
• Rilis semantik secara otomatis menginstal Capgo bundle aplikasi, juga menggunakan Capgo saluran.
• Hal ini sesuai dengan pembangunan XCode Cloud biner aplikasi.

Langkah selanjutnya

Saya sedang dalam fase pengembangan aplikasi ini. Saya akan segera membuatnya tersedia untuk tester melalui TestFlight (untuk iOS). Mengingat kekuatan Capgo, saya pasti akan menginstal versi gratis aplikasi ke AppStore untuk tes, yang akan diperbarui secara teratur dengan Capgo selama tes. Saya kemudian akan menginstal versi lain (berbayar) aplikasi di AppStore, di bawah rekaman lain, dan juga memperbarui itu secara teratur dengan Capgo.

Saya berharap dapat menambahkan verifikasi pra-membangun yang lebih baik untuk Capgo bundle upload Persyaratan saya masukkan ke dalam konfigurasi rilis semantik saya.

Saya memiliki rilis semantik yang bersih, sederhana, dan dapat diulang kembali 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 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 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 dan https://www.rapido.cloud (under development).

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 detail implementasi alur kerja produk di Capgo Live Updates, Ringkasan untuk detail implementasi di Ringkasan, Fitur untuk detail implementasi di Fitur Pengaturan Pembaruan untuk detail implementasi di Update Behavior, dan Jenis Update untuk detail implementasi di Jenis Update.