How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

1. Introduzione

At 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 attracted me with its promise to make mobile app deployments much more simple, much more rapid and flexible than going through the standard Apple AppStore/Google PlayStore delivery process. This is my first mobile application which I am pushing to the stores, having concentrated in the past on web apps, usually developed on the Salesforce Experience Cloud.

I eroi temevo la curva d'apprendimento per rendere questo progetto un successo, ma riuscii a mettere il mio app su Apple TestFlight con facilità. Riuscii poi a utilizzare Capgo CapacitorUpdater per distribuire le mie aggiornamenti molto più velocemente.

La mia prima richiesta e caso di test era distribuire per me stesso per testare il mio app come una vera app mobile sul mio telefono, invece di testare in un emulatore mobile o in un simulatore tramite il browser mobile Nexus suggerito da IIonic. Questo perché il mio app utilizza funzionalità native come la Geolocalizzazione o l'accesso alla Galleria delle foto e alla Fotocamera. Non avendo l'esperienza passata di testare un Capacitor app mobile, non ero sicuro se tutto sarebbe andato a buon fine : nulla di meglio che testare l'app reale, in condizioni reali!

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

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

Quindi ora ho la mia consegna ai Capgo server che funziona correttamente, ho bisogno di automatizzare questo e inserirlo nel mio pipeline CI/CD.

Questa è la mia organizzazione del mio modello di branching e rilascio

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

• si svolge il su feature/... rami che si staccano main, e vengono fusi in main che è il riferimento per la maggior parte delle ramificazioni di sviluppo, fuori dalla manutenzione e dalle funzionalità specifiche per le consegne personalizzate (ne parlerò in seguito)
• le rilasci vengono attivati dai rami di rilascio che possono essere : production, rami di rilascio prerelease (alpha, beta, nightly, ecc.) e anche rami specifici per i clienti o contestuali per le consegne personalizzate
• le rilasci vengono attivati da una richiesta di pull che viene fusa in un ramo di rilascio. Non utilizzo i rilasci attivati dai 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/stories/manuelherrera/git-branching-strategies-in-2022

Nota a margine su come funziona semantic-release :

In una branca di distribuzione, quando viene attivato semantic-release, 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 funzionalità consegnate. Le correzioni creeranno una nuova versione di patch, mentre le funzionalità creeranno una nuova versione minore. Includerà anche le versioni 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.

Aggiornerebbe inoltre tutti i tuoi pull request Git (Github, nel mio caso) e le relative issue con commenti che li collegano al tag e alla release. Infine, in questa Github release, attaccherà asset come il codice code, i binari se necessario, ecc. CHANGELOG.md4. Le branche, le release/prerelease, i canali in semantic release e in __CAPGO_KEEP_0__

Quindi, per le distribuzioni Capgo, voglio che semantic release faccia le seguenti cose.

So what I want semantic release to do for Capgo deployments is the following.

__CAPGO_KEEP_0__ hanno sviluppato e documentato la propria versione del “Conventional Commits”

Capgo have developed and documented their own version of the “Conventional Commits” standard-version Come gestisco il rilascio semantico con CapGo CapacitorUpdater? standard-version (https://github.com/Cap-go/standard-version), e i loro capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) altresì capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repository. Hanno documentato sul loro blog lo schema di versione utilizzato da Capgo nei loro 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 anche segue (ovviamente !)

Quindi è fantastico, e mi è un sollievo perché utilizzo semantic-release in modo estensivo.

Inoltre, desidero che la rilascio semantico generi le distribuzioni dell'applicazione su diversi canali.

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

Capgo fornisce la caratteristica dei “canali” che è esattamente ciò che anche la rilascio semantico supporta, quindi sono entusiasta di farli funzionare insieme. Questo si adatta anche alle diverse costruzioni di rami gestite da XCode Cloud (vedi di più su questo di seguito).

I numeri di versione Semver generati dalla rilascio semantico sui prerelease hanno l'aspetto di 1.0.0-alpha.1I successivi costruzioni su questo rama incrementeranno il numero di costruzione a 1.0.0-alpha.2ecc. Anche se non è documentato esplicitamente, questi numeri di versione sono supportati da Capgo, il che è una notizia meravigliosa per me: utilizzerò i canali della rilascio semantico e i prerelease per generare versioni dell'applicazione con Capgo canali.

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

Per automatizzare la distribuzione dei pacchetti dell'applicazione su Capgo, è necessario utilizzare il comando Capgo CLI bundle uploadInserisci npx @capgo/cli@latest bundle upload --help per ottenere le numerose opzioni di caricamento. Tra queste, useremo le seguenti :

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

• IL CANALE è il Capgo canale a cui vogliamo distribuire (ad esempio alpha)
• LA VERSIONE è generata da semantic release (ad esempio 1.0.0-alpha.1)
• CAPGO_APIKEY è fornito da Capgo per identificare in modo univoco il tuo pipeline di integrazione continua e distribuzione (ad esempio
• CAPGO_IDAPP è fornito da Capgo per identificare in modo univoco il tuo'applicazione (ad esempio com.mystartup.mysuperapp)

6. La mia configurazione di rilascio semantico + Capgo CapacitorUpdate

Infine, come si abbinano tutte queste cose ?

Il versione del pacchetto dell'applicazione costruita con semantic release 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 Github Actions, è molto semplice. Questo sarà molto simile su altre piattaforme di integrazione continua e distribuzione .

# ./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 semplicemente l'ambiente NodeJS, poi chiama semantic release.

For ogni merge su una branca elencata in branches, la rilascio semantico attiverà un'installazione. Imposta CAPGO_APIKEY in i segreti del tuo repository. Aggiorna il tuo CAPGO_APPID qui.

La configurazione del rilascio semantico è impostata nel suo .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 impostano la configurazione delle branch (name), mappate al canale Capgo (channel) e come verrà chiamato il numero di versione prerelease (prerelease). Ad esempio, se branch.prerelease = "development", il numero di versione generato dal rilascio semantico sarà x.y.z-development.n
  • installazioni sul alphae alpha-nocapgo le rami deployeranno l'app sul canale, ma con nomi di prerelease diversi nel numero di versione alphao
  • deployeranno sul canale dev-rupertma con nomi di prerelease diversi nel numero di versione dev-paul o developmentchannel on Capgo, all with the same developmentma con nomi di prerelease diversi nel numero di versione
• 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 deployeranno sul canalehttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator o CHANGELOG.md
• @semantic-release/git : commetto 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 - Non costruisco ancora per Android
• @semantic-release/github : allego il CHANGELOG.md file al rilascio Github come risorsa
• @semantic-release/exec: utilizzo questi 2 comandi per preparare la costruzione dell'app (prepareCmd) e poi per costruire e distribuire in modo efficace il bundle dell'app sulle Capgo server (publishCmd)

Noterete che non ci sono spiegazioni su come vogliamo che il numero di versione venga calcolato e incrementato, come generare un changelog, un Github tag o rilascio, ecc. : tutto è gestito di default da semantic release, con una configurazione minima.

Costruzione di nuovi binari con XCode Cloud

Integrazione di tutto questo con la costruzione di nuovi 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'è un cambio sulla branch che desidero utilizzare per questo (ad esempio production)
• su questa branch, configuro XCode Cloud per costruire solo quando il CHANGELOG.md il file è aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• Posso attivare costruzioni su diverse branch per simulare la distribuzione per diversi canali. 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 quindi, se lo volessi, potrei distribuire un'applicazione AppStore diversa per ogni applicazione cliente personalizzata distribuita da una release branch personalizzata, come menzionato in precedenza.

Costruzione di binari di app su XCode Cloud con Capgo canali

7. Conclusione

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

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

Passaggi successivi

I 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 sul AppStore per le prove, che verrà aggiornata regolarmente con Capgo durante le prove. Deployerò quindi un'altra versione (a pagamento) dell'app sul AppStore, sotto un altro record, e l'aggiornerei regolarmente con Capgo.

Spero di poter aggiungere una verifica pre-compilazione migliore di Capgo bundle upload nelle mie impostazioni di rilascio semantico.

Ora ho un flusso di rilascio semantico pulito, semplice e riproducibile per future app mobili sviluppate con Ionic + Angular + Capacitor.

Autore - Rupert Barrow

Ho più di 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 successo Salesforce in Francia, prima di intraprendere una nuova avventura come solopreneur Salesforce con il mio offerta di prodotti Rapido Cloud Troverai me su LinkedIn a

https://linkedin.com/in/rbarrow Potrai prendere uno sguardo alle nostre offerte Salesforce a.

https://www.rapido-companion.app Rapido Cloud e https://www.rapido.cloud (in fase di sviluppo).

Continua da Come Rapido Cloud gestisce la rilascio semantico con Capgo CapacitorUpdater

Se stai utilizzando Come 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 Features, 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.