How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

1. Introduzione

A Rapido Cloud (www.rapido.cloud), I am developing a mobile application for Salesforce clients to easily deploy their own branded mobile application without having to go through the difficult loops of using the Salesforce Mobile SDK or the Salesforce Mobile Publisher.

I have developed this mobile app on a modern and “standard” platform with widespread components and tools including Ionic 8, Angular 18, TypeScript, Capacitor and now Capgo CapacitorUpdater. These are more simple to handle for clients who do not want to manage Salesforce platform specifics such as Lightning Web Components; and its easier and cheaper for me to recruit developers and maintainers of Ionic + Angular mobile applications.

This article explains my design, my choices and implementation which make Capgo and 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. Why use Capgo ? Why use semantic-release ?

Capgo CapacitorUpdater mi ha affascinato con la sua promessa di rendere i rilasci di applicazioni mobili molto più semplici, rapidi e flessibili rispetto al processo standard di consegna Apple AppStore/Google PlayStore. Questo è il mio primo'applicazione mobile che sto pubblicando nei negozi, avendo concentrato in passato sulle app web, solitamente sviluppate sulla piattaforma Salesforce Experience Cloud.

I ero piuttosto preoccupato della curva di apprendimento per rendere questo progetto riuscito, ma riuscii a caricare il mio app su Apple TestFlight con facilità. Poi potevo utilizzare Capgo CapacitorUpdater per distribuire le mie aggiornamenti molto più velocemente.

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 !

Quindi Capgo CapacitorUpdater mi ha aiutato ad aggiornare il mio'applicazione sul mio telefono, in tempo reale, 1 minuto dopo aver salvato una nuova funzionalità o correzione nel mio codice code : così liberatorio, e così flessibile, e facile da configurare!

3. Il mio modello di branching e rilascio, e come semantic-release si inserisce

Quindi ora ho il mio rilascio a Capgo server funzionante correttamente, ho bisogno di automatizzare questo e inserirlo nel mio pipeline CI/CD.

Questo è il modo in cui organizzo il mio modello di rilascio e branching

Per ogni applicazione, indipendentemente se mobile, web o Salesforce :

• lo sviluppo avviene su feature/... rami derivati main, e vengono mergeati in main che è il riferimento per la maggior parte delle ramificazioni di sviluppo, fuori dalla manutenzione e dalle funzionalità specifiche per i rilasci personalizzati (ne sappiamo di più in seguito)
• i rilasci sono attivati dai rami di rilascio che possono essere : production, rami prerelease (alpha, beta, nightly, ecc.) e anche rami specifici per i clienti o contestuali per i rilasci personalizzati
• le deployment sono attivati da una richiesta di pull sono fuso in una branca di deployment. Non utilizzo deployment attivati da tag perché semantic release gestisce i tag e tutto il resto per me.

Di base, si tratta del flusso Gitlab :

Flusso Gitlab - fonte https://faun.dev/c/storie/manuelherrera/strategie-di-branching-in-github-2022

Nota a lato su come funziona semantic-release :

In una branca di deployment, quando semantic-release viene attivato, calcolerà automaticamente il nuovo numero di versione su questa branca, in base al numero di versione del tag precedente sulla branca e alle correzioni o alle funzionalità consegnate. Le correzioni creeranno una nuova versione patch, mentre le funzionalità creeranno una nuova versione minore. Inoltre, includerà automaticamente il prerelease alpha, betaecc. nel numero di versione.

Semantic release genera il changelog dai tuoi commit, raggruppando le correzioni e le funzionalità come definito nei commit convenzionali (vedi https://www.conventionalcommits.org/en/about) e configurato in semantic release.

It aggiornerà inoltre tutti i tuoi pull request git (Github, nel mio caso) e le relative issue con commenti che li collegano alla tag e alla release. Infine, in questa Github release, attaccherà asset come il codice code, i binari se necessario, ecc. CHANGELOG.md, ecc.

4. Ramificazioni, rilasci/prerelease, canali in semantic release e in Capgo

Quindi cosa voglio che semantic release faccia per Capgo deployment è quanto segue.

Voglio che semantic release generi il numero di versione

Capgo hanno sviluppato e documentato la loro versione della “Conventional Commits” standard-version strumento, con il loro fork del repository standard-version (https://github.com/Cap-go/standard-version), e la loro capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) nonché 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/) i bundle JavaScript seguono la "standard" semver "Semantic Versioning" (https://semver.org) che semantic-release segue (ovviamente !)

Quindi è tutto a posto, e mi è un grande sollievo perché utilizzo semantic-release estensivamente.

Voglio inoltre che la rilascio semantico generi le distribuzioni dell'applicazione su diversi canali

Come menzionato sopra, ho bisogno di distribuire versioni prerelease da branch come alpha, beta, nightly etc., ma anche versioni specifiche per i clienti su branch come production-customer-jones, production-customer-doe, etc.

Capgo offre la funzione "canali" che è esattamente ciò che anche semantic release supporta, quindi sono entusiasta di farli funzionare insieme. Questi si adattano anche alle diverse costruzioni di branch gestite da XCode Cloud (vedi di più su questo di seguito).

Le versioni di semver generate da semantic release sui prerelease hanno l'aspetto di 1.0.0-alpha.1. Le costruzioni successive su questa branch incrementeranno il numero di costruzione a 1.0.0-alpha.2, ecc. Sebbene non sia documentato esplicitamente, questi numeri di versione sono supportati da Capgo, il che è una notizia meravigliosa per me: utilizzerò i canali di rilascio semantic e prerelease per generare versioni del mio app con Capgo canali.

5. Come posso utilizzare Capgo per rilasciare la mia applicazione?

Per automatizzare il deployment dei pacchetti della tua app su Capgo, devi utilizzare il comando Capgo CLI bundle upload. Tipo npx @capgo/cli@latest bundle upload --help per ottenere le numerose opzioni di upload. Tra queste, useremo le seguenti:

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

• CHANNEL è il canale Capgo a cui vogliamo distribuire (ad esempio) alpha)
• VERSIONE è generata da semantic release (ad esempio) 1.0.0-alpha.1)
• CAPGO_APIKEY è fornito da Capgo per identificare univocamente il tuo pipeline di integrazione continua e distribuzione (ad esempio)
• CAPGO_APPID è fornito da Capgo per identificare univocamente la tua applicazione (ad esempio) com.mystartup.mysuperapp)

6. La mia rilascio semantico + Capgo setup di CapacitorUpdate

Infine, come si abbinano tutte queste cose?

Le versioni del pacchetto dell'applicazione costruite con rilascio semantico e Github Actions

L'automazione del rilascio semantico con Github Actions

La bellezza del rilascio semantico è che l'automazione della distribuzione, nella forma di un flusso di lavoro di Github Actions, è molto semplice. Questo sarà molto simile su altre piattaforme CI/CD.

# ./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 }}

Questo installa solo l'ambiente NodeJS, poi chiama il rilascio semantico.

Per ogni merge su una branca elencata in branchesRilascio semantico attiverà una distribuzione. CAPGO_APIKEY impostare CAPGO_APPID impostare

aggiornare il tuo repository qui. .releaserc.json file di configurazione. Ecco le mie impostazioni, spiegate di seguito :

// .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 impostazioni le impostazioni delle branch (name), mapped to the Capgo channel (channel) e come il numero di versione prerelease sarà chiamato (prerelease). Ad esempio, se branch.prerelease = "development"il numero di versione generato da semantic release sarà x.y.z-development.n
  • deployments al alphae alpha-nocapgo le branch saranno entrambe distribuite sull' alphacanale, ma con nomi di versione prerelease diversi nel numero di versione
  • deployments alle branch di sviluppo dev-ruperto dev-paul saranno entrambi distribuiti sul developmentcanale su Capgo, tutti con lo stesso developmentparola chiave prerelease nel numero di versione
• verifyConditions : nella prima fase di rilascio semantico, controlla se ha l'accesso corretto a Github. Spero di aggiungere un controllo di autenticazione per il Capgo CLI qui più tardi
• @semantic-release/commit-analyzer : roba standard di rilascio semantico - vedi la loro documentazione (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator : generare il file di changelog come CHANGELOG.md
• @semantic-release/git : commit i seguenti file che sono stati aggiornati dalla build Ionic dell'applicazione e dal lavoro di rilascio semantico (package.json, CHANGELOG.md e ios/App/App.xcodeproj/project.pbxproj context
• @semantic-release/github non costruisco per Android, ancora) CHANGELOG.md file to the Github release as an asset
• @semantic-release/exec: utilizza questi 2 comandi per preparare la costruzione dell'app (prepareCmd) e poi costruisci e distribuisci in modo efficace il bundle dell'app sulle Capgo server (publishCmd)

Si noterà che non ci sono spiegazioni sulla versione da utilizzare e come incrementarla, sulla generazione di un changelog, di un Github tag o rilascio, ecc. : tutto è gestito di default da semantic release, con una configurazione minimale.

Costruzione di nuovi binari con XCode Cloud

Integrare tutto questo con XCode Cloud per costruire nuove versioni del file binario dell'applicazione è semplice (non sto ancora distribuendo su Google Play, ma quel build dovrebbe essere simile) :

• Configuro un processo XCode Cloud per costruire quando c'è una modifica sulla branca che desidero utilizzare per questo (ad esempio production)
• su questa branca, configuro XCode Cloud per costruire solo quando il CHANGELOG.md file è stato aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• Posso attivare costruzioni su diverse branch per simulare la distribuzione per canali diversi. In ogni configurazione di costruzione di XCode Cloud su una diversa branch, imposto manualmente una variabile di ambiente con il valore di branch.channel impostato in releaserc.json (sì, si tratta di una duplicazione manuale) e poi, se lo desiderassi, potrei distribuire un'applicazione AppStore diversa per ogni applicazione di cliente personalizzata distribuita da una branca di rilascio personalizzata, come menzionato in precedenza.

Costruisco binari di app su XCode Cloud con Capgo canali

7. Conclusioni

In conclusione, sono molto felice di aver potuto integrare Capgo CapacitorUpdater nella mia pipeline di rilascio semantico standard, rapidamente entro il termine del periodo di prova di 14 giorni, e il risultato è il seguente :

• i numeri di versione dei bundle vengono generati automaticamente da rilascio semantico e sono compatibili con i Capgo server
• rilascio semantico distribuisce automaticamente i bundle di applicazione Capgo, facendo anche uso dei Capgo canali
• questo si adatta bene alle costruzioni di binari di app di XCode Cloud

Passaggi successivi

Sono attualmente nella fase di sviluppo di questa app. La renderò disponibile rapidamente ai tester attraverso TestFlight (per iOS). Considerando la potenza di Capgo, deployerò sicuramente una versione gratuita dell'app sullo Store per i test, che verrà aggiornata regolarmente con Capgo durante i test. Deployerò poi un'altra (a pagamento) versione dell'app sullo Store, sotto un altro record, e aggiornarò anche quella regolarmente con Capgo.

Spero di poter aggiungere una verifica pre-costruzione migliore dei Capgo prerequisiti nella mia configurazione di rilascio semantico. bundle upload Ora ho una pipeline di rilascio semantico pulita, semplice e riproducibile per future app mobili sviluppate con 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.

Canali __CAPGO_KEEP_0__ vengono costruiti su XCode Cloud

I ho 22 anni di esperienza con Salesforce, sia come cliente e utente, sia come partner e integratore, architetto, sviluppatore, analista di business e consulente. Ho co-fondato e co-gestito Altius Services come COO e CTO per 13 anni, un partner SI di Salesforce di successo in Francia, prima di intraprendere una nuova avventura come Salesforce solopreneur con il mio Rapido Cloud troverai me su LinkedIn a

https://linkedin.com/in/rbarrow troverai le nostre offerte Salesforce a.

https://www.rapido-companion.app e https://www.rapido.cloud (in fase di sviluppo). Continua da Come Rapido Cloud gestisce la rilascio semantico con CapacitorUpdater

Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

__CAPGO_KEEP_0__ CapacitorUpdater How Rapido Cloud gestisce la rilascio semantico con Capgo CapacitorUpdater per pianificare la consegna di aggiornamenti in tempo reale, connettilo con Capgo Aggiornamenti in tempo reale per il flusso di lavoro del prodotto in Capgo Aggiornamenti in tempo reale Panoramica per i dettagli di implementazione in Panoramica Caratteristiche per i dettagli di implementazione in Caratteristiche Comportamento dell'aggiornamento per i dettagli di implementazione in Comportamento dell'aggiornamento, e Tipi di aggiornamento per i dettagli di implementazione in Tipi di aggiornamento