Come Rapido Cloud gestisce il Semantic Release con Capgo CapacitorUpdater

1. Introduzione

In Rapido Cloud (www.rapido.cloud), sto sviluppando un'app mobile per i clienti Salesforce, per permettere loro di distribuire facilmente la propria app branded senza dover affrontare i complessi cicli di Salesforce Mobile SDK o Salesforce Mobile Publisher.

Ho sviluppato questa app su una piattaforma moderna e "standard" con componenti e tool diffusi, tra cui Ionic 8, Angular 18, TypeScript, Capacitor e ora Capgo CapacitorUpdater. Sono molto più semplici da gestire per i clienti che non vogliono occuparsi delle specificità di Salesforce come i Lightning Web Components; inoltre, per me è più facile ed economico reclutare sviluppatori e manutentori di app Ionic + Angular.

Questo articolo spiega il mio design, le mie scelte e l'implementazione che rendono Capgo e semantic-release una soluzione semplicissima per gestire tutti i deployment in automatico tramite Github Actions. Tutto è stato progettato, testato e documentato durante i 14 giorni di free trial di Capgo CapacitorUpdater.

2. Perché usare Capgo? Perché usare semantic-release?

Capgo CapacitorUpdater mi ha colpito per la promessa di rendere il deployment delle app mobile molto più semplice, rapido e flessibile rispetto al processo standard di Apple AppStore o Google PlayStore. Questa è la mia prima applicazione mobile destinata agli store, dopo essermi concentrato in passato sulle web app, solitamente sviluppate su Salesforce Experience Cloud.

Temevo un po' la curva di apprendimento per far funzionare tutto, ma sono riuscito a caricare l'app su Apple TestFlight con facilità. A quel punto, ho potuto usare Capgo CapacitorUpdater per distribuire i miei aggiornamenti molto più velocemente.

Il mio primo requisito e caso di test era il deploy per testare l'app come vera applicazione mobile sul mio telefono, invece di usare un emulatore o il browser Nexus suggerito da Ionic. Questo perché la mia app usa feature native come la Geolocation o l'accesso alla Galleria Foto e alla Camera. Non avendo esperienza nel testare una Capacitor mobile app, non ero sicuro che tutto funzionasse correttamente: non c'è modo migliore che testare l'app reale, in condizioni reali!

Così Capgo CapacitorUpdater mi ha aiutato ad aggiornare la mia app sul cellulare, live, un minuto dopo aver salvato una nuova feature o un fix nel mio code : un sollievo incredibile, ed è così flessibile e facile da configurare!

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

Ora che il rilascio verso i server Capgo funziona correttamente, devo automatizzarlo e integrarlo nella mia pipeline CI/CD.

Ecco come organizzo il mio modello di branching e release

Per ogni applicazione, che sia mobile, web o Salesforce:

• lo sviluppo viene eseguito su feature/... branch derivati da main, che vengono poi mergeati in main che è il riferimento per la maggior parte dei branch di sviluppo, escludendo la manutenzione e le feature specifiche per consegne custom (ne parleremo più avanti)
• vengono triggerati i deployment dai branch di release che possono essere: production, branch di prerelease (alpha, beta, nightly, ecc.) e anche branch specifici per cliente o per contesto per consegne custom
• i deployment vengono attivati da una pull request che viene mergeata in un branch di deployment. Non uso deployment basati su tag perché semantic-release gestisce i tag e tutto il resto per me.

In sostanza, questo è il Gitlab Flow:

Gitlab Flow - sorgente https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

Una nota su come funziona semantic-release:

In un branch di deployment, quando viene attivato semantic-release, calcolerà automaticamente il nuovo numero di versione su questo branch, in base alla versione del tag precedente sul branch e ai fix o alle feature rilasciate. I fix creeranno una nuova patch version, mentre le feature creeranno una nuova minor version. Include anche automaticamente la prerelease alpha, beta, ecc. nel numero di versione.

Semantic release genera il changelog dai tuoi commit, raggruppando fix e feature come definito nei conventional commits (vedi https://www.conventionalcommits.org/it/about) e configurato in semantic release.

Aggiornerà anche tutte le tue pull request mergeate su git (Github, nel mio caso) e le relative issue con commenti che le collegano al tag e alla release. Infine, in questa release Github, allegherà asset come il source code, i binari se necessari, CHANGELOG.md, ecc.

4. Branch, release/prerelease, channel in semantic release e in Capgo

Quindi, ecco cosa voglio che semantic release faccia per i deployment su Capgo.

Voglio che semantic release generi il numero di versione

Capgo hanno sviluppato e documentato la propria versione dei “Conventional Commits” standard-version tool, con il loro repo forkato standard-version (https://github.com/Cap-go/standard-version), e i propri capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) oltre a capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repo. Hanno documentato sul loro blog lo schema di versionamento usato da Capgo nei loro deploy (https://capgo.app/blog/come-funziona-il-versionamento-in-capgo/). I bundle JavaScript seguono il semver “standard” (“Semantic Versioning” (https://semver.org) che semantic-release segue anch'esso (ovviamente!)

Quindi è fantastico, e per me è un sollievo perché uso semantic-release ampiamente.

Voglio anche che semantic release generi i deployment dell'app su diversi channel

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

Capgo offre la funzionalità "channels", che è esattamente ciò che supporta anche semantic release, quindi sono entusiasta di farli lavorare insieme. Questi si integrano perfettamente anche con le diverse build di branch gestite da XCode Cloud (vedi più sotto).

I numeri di versione Semver generati da semantic release per le prerelease appaiono così: 1.0.0-alpha.1. Le build successive su questo branch incrementeranno il build number a 1.0.0-alpha.2, ecc. Anche se non è documentato esplicitamente, questi numeri di versione sono supportati da Capgo, il che è un'ottima notizia per me: userò i canali di semantic release e le prerelease per generare le versioni della mia app con i canali Capgo.

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

Per automatizzare il deployment dei bundle della tua app su Capgo, devi usare il comando Capgo CLI di Capgo bundle upload. Digita npx @capgo/cli@latest bundle upload --help per visualizzare 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 su cui vogliamo fare il deploy (es. alpha)
• VERSION è generata da semantic release (es. 1.0.0-alpha.1)
• CAPGO_APIKEY è fornita da Capgo per identificare univocamente il login della tua pipeline CI/CD
• CAPGO_APPID è fornita da Capgo per identificare univocamente la tua applicazione (es. com.mystartup.mysuperapp)

6. Il mio setup di semantic release + Capgo CapacitorUpdate

In definitiva, come si integra tutto questo?

Versioni dell'app bundle buildate con semantic release e Github Actions

Automazione di semantic release con Github Actions

Il bello di semantic release è che l'automazione del deployment, tramite un workflow di Github Action, è semplicissima. 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 l'ambiente NodeJS e poi chiama semantic release.

Per ogni merge su un branch elencato in branches, semantic release avvierà un deployment. Imposta CAPGO_APIKEY nei secret del tuo repository. Aggiorna il tuo CAPGO_APPID qui.

Il comportamento di semantic release è definito nel suo .releaserc.json file di configurazione. Ecco le mie impostazioni, spiegate qui sotto:

// .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 imposta la configurazione dei branch (name), mappati sul canale Capgo (channel) e come verrà chiamato il numero della versione prerelease (prerelease). Ad esempio, se branch.prerelease = "development", il numero di versione generato da semantic release sarà x.y.z-development.n
  • i deployment sul alphae alpha-nocapgo entrambe le branch deployeranno l'app sul alphachannel, ma con nomi prerelease diversi nel numero di versione
  • deployment sulle branch di sviluppo dev-ruperto dev-paul distribuiranno entrambi su developmentchannel su Capgo, tutti con lo stesso developmentkeyword prerelease nel numero di versione
• verifyConditions : nella prima fase di semantic release, verifica di avere l'accesso corretto a Github. Spero di aggiungere un controllo di autenticazione per Capgo CLI in seguito
• @semantic-release/commit-analyzer : operazioni standard di semantic release - vedi la loro documentazione (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator : genera il file changelog come CHANGELOG.md
• @semantic-release/git : commit i seguenti file aggiornati dalla build Ionic dell'applicazione e dal processo di semantic release ("package.json, CHANGELOG.md e ios/App/App.xcodeproj/project.pbxproj - non faccio ancora la build per Android)
• @semantic-release/github : allega il CHANGELOG.md file alla release di Github come asset
• @semantic-release/exec: usa questi 2 comandi per preparare la build dell'app (prepareCmd) e poi per buildare e deployare efficacemente l'app bundle sui server Capgo (publishCmd)

Noterai che non c'è bisogno di impazzire a spiegare come calcolare e incrementare il numero di versione, come generare un changelog, un tag o una release Github, ecc.: tutto è gestito di default da semantic release con una configurazione minima.

Creare nuove binarie con XCode Cloud

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

• Ho configurato un processo XCode Cloud per avviare il build quando viene rilevata una modifica sul branch che intendo utilizzare per questo (es. production)
• su questo branch, ho impostato XCode Cloud per buildare solo quando il CHANGELOG.md file viene aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• Posso triggerare build su branch diversi per simulare il deployment per diversi channel. In ogni configurazione di XCode Cloud su un branch differente, imposto manualmente una variabile d'ambiente con il valore di branch.channel impostato in releaserc.json (sì, è una duplicazione manuale) e poi, se volessi, potrei deployare un'applicazione AppStore diversa per ogni applicazione cliente personalizzata deployata da un release branch custom, come menzionato prima.

Build di binari app su Xcode Cloud con i canali Capgo

7. Conclusione

In conclusione, sono molto felice di aver integrato Capgo CapacitorUpdater nella mia pipeline di semantic release standard, in pochissimo tempo durante la trial di 14 giorni; il risultato è il seguente:

• i numeri di versione dei bundle vengono generati automaticamente da semantic-release e sono compatibili con i server Capgo
• semantic release deploya automaticamente i bundle dell'applicazione Capgo, sfruttando anche i canali Capgo
• si integra perfettamente con le build di XCode Cloud per i binari dell'applicazione

Prossimi passi

Al momento l'app è in fase di sviluppo. La renderò presto disponibile ai tester tramite TestFlight (per iOS). Data la potenza di Capgo, pubblicherò sicuramente una versione gratuita sull'App Store per i test, che aggiornerò regolarmente con Capgo. Successivamente pubblicherò un'altra versione (a pagamento) sull'App Store, sotto un altro record, aggiornandola anch'essa regolarmente con Capgo.

Spero di aggiungere una migliore verifica pre-build di Capgo bundle upload dei prerequisiti nella mia configurazione di semantic release.

Ora ho una pipeline di semantic release pulita, semplice e riproducibile per le future app mobile sviluppate con Ionic + Angular + Capacitor.

Autore - Rupert Barrow

Ho oltre 22 anni di esperienza con Salesforce come cliente, utente, partner, integratore, architetto, sviluppatore, business analyst 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 partire per una nuova avventura come solopreneur Salesforce con la mia Cloud Rapido offerta di prodotti.

Puoi trovarmi su LinkedIn qui: https://linkedin.com/in/rbarrow.

Puoi dare un'occhiata alle nostre offerte Salesforce su https://www.rapido-companion.app e https://www.rapido.cloud (in fase di sviluppo).

Continua: Come Rapido Cloud gestisce Semantic Release con Capgo CapacitorUpdater

Se stai usando Come Rapido Cloud gestisce il Semantic Release con Capgo CapacitorUpdater per pianificare la distribuzione di live update, collegalo a Live Updates di Capgo per il workflow del prodotto in Capgo Live Updates, Panoramica per i dettagli di implementazione nell'Overview, Funzionalità per i dettagli implementativi in Features, Comportamento degli aggiornamenti per i dettagli implementativi in Update Behavior, e Tipi di aggiornamento per i dettagli di implementazione in Tipi di aggiornamento.