Come Rapido Cloud gestisce la rilascio semantico con Capgo CapacitorUpdater

1. Introduzione

All'interno di Rapido Cloud (www.rapido.cloud), sto sviluppando un'applicazione mobile per i clienti Salesforce per poter facilmente distribuire la propria applicazione mobile personalizzata senza dover passare attraverso i difficili passaggi di utilizzo della Salesforce Mobile SDK o del Salesforce Mobile Publisher.

Ho sviluppato questa app mobile su una piattaforma moderna e “standard” con componenti e strumenti diffusi, tra cui Ionic 8, Angular 18, TypeScript, Capacitor e ora Capgo CapacitorUpdater. Questi sono più semplici da gestire per i clienti che non vogliono gestire le specifiche della piattaforma Salesforce, come i Lightning Web Components; e per me è più facile e economico reclutare sviluppatori e mantenitori di applicazioni mobili Ionic + Angular.

Questa pagina spiega il mio design, le mie scelte e l'implementazione che rendono Capgo e semantic-release molto facile da gestire per l'automatizzazione di tutti i deployment tramite Github Actions. Tutti questi sono stati progettati, testati e documentati durante il periodo di prova gratuito di 14 giorni di Capgo CapacitorUpdater.

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

Capgo CapacitorUpdater mi ha attirato con la sua promessa di rendere i deployment delle app mobili molto più semplici, molto più rapidi e flessibili rispetto al processo standard di consegna Apple AppStore/Google PlayStore. Questa è la mia prima app mobile che sto pubblicando sui negozi, essendo concentrato in passato su app web, solitamente sviluppate sulla piattaforma Salesforce Experience Cloud.

Ero piuttosto spaventato dalla curva di apprendimento per renderla vincente ma sono riuscito a pubblicare la mia app su Apple TestFlight con facilità. Ero quindi in grado di 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 il Capgo CapacitorUpdater mi ha aiutato ad aggiornare la mia applicazione sul mio mobile, 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 impostare !

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.

Questo è come organizzo il mio modello di branching e rilascio

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

• la si svolge su feature/... si stacca da main, e vengono fuse in main che è il riferimento per la maggior parte delle branch di sviluppo, fuori dalla manutenzione e dalle funzionalità specifiche per le consegne personalizzate (ne parlerò in seguito)
• le consegne vengono attivate Dal rilascio delle branch Ciò che può essere : production, branch prerelease (alpha, beta, nightly, ecc.) e anche branch specifici per i clienti o contestuali per le consegne personalizzate
• Irrocimenti sono attivati da una richiesta di pull Sto per essere integrato in una branca di distribuzione. Non utilizzo le distribuzioni attivate dai tag perché semantic release gestisce i tag e tutto il resto per me.

In sostanza, si tratta del flusso Gitlab :

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

Nota a lato su come funziona semantic-release :

In una branca di distribuzione, 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 ai fissaggi o alle funzionalità consegnati. I fissaggi creeranno una nuova versione di patch, mentre le funzionalità creeranno una nuova versione minore. Includerà anche le versioni prerelease automaticamente alpha, betaecc. nella versione del numero.

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.

Inoltre, aggiornerebbe tutti i tuoi pull request (Github, nel mio caso) e relative issue con commenti che li collegano alla tag e alla release. Infine, in questa Github release, attaccherà asset come fonti code, eseguibili se necessario, CHANGELOG.mdecc.

4. Ramificazioni, release/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 propria versione della “Conventional Commits” standard-version strumento, con il loro fork del repository standard-version (https://github.com/Cap-go/standard-versione le loro capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionanche capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionrepos. Hanno documentato sul loro blog lo schema di versione utilizzato da Capgo nelle loro distribuzioni (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 !)

Così va bene, e mi è un sollievo perché utilizzo semantic-release in modo estensivo.

I desidero anche che semantic release generi le distribuzioni dell'applicazione su diversi canali

Come menzionato sopra, ho bisogno di distribuire la versione 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 funzione dei “canali” che è esattamente ciò che semantic release supporta anche, quindi sono entusiasta di farli funzionare insieme. Questi si adattano anche alle diverse costruzioni di rami gestite da XCode Cloud (vedi di più su questo di seguito).

Il numero di versione Semver generato da semantic release sulle prerelease assomiglia a 1.0.0-alpha.1. Le costruzioni successive su questo ramo 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 di semantic release e 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 upload. Tipo npx @capgo/cli@latest bundle upload --help per ottenere le numerose opzioni di caricamento. Tra quelle, utilizzeremo 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 CI/CD di accesso
• CAPGO_APPID è 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?

Le versioni del pacchetto dell'applicazione costruite con semantic release e Github Actions

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 assomiglia molto ad altre piattaforme di 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 mazzo di rilascio su una branca elencata in branchesLa rilascio semantico attiverà un deployment. CAPGO_APIKEY impostare CAPGO_APPID nel segreti del tuo repository.

aggiornare il tuo .releaserc.json qui.

// .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 Il comportamento della rilascio semantico è impostato nel suoname), mapped to the Capgo channel (channelEcco le mie impostazioni, spiegate di seguito:prereleaseimpostare la configurazione delle branch ( branch.prerelease = "development"mappate al canale __CAPGO_KEEP_0__ ( x.y.z-development.n
  • e come verrà chiamato il numero di versione prerelease ( alphaAd esempio, se si utilizza il canale "alpha", il numero di versione generato dalla rilascio semantico sarà "alpha.", alpha-nocapgo le branche deployeranno l'app sul alphacanale, ma con nomi di prerelease diversi nel numero di versione
  • le distribuzioni alle sottobranche del developer dev-ruperto dev-paul deployeranno entrambe sul developmentcanale su Capgo, tutte con lo stesso developmentparola chiave di prerelease nel numero di versione
• verifyConditions : nella prima fase di rilascio semantico, controlla che abbia l'accesso corretto a Github. Spero di poter 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 : genera il file di changelog come CHANGELOG.md
• @semantic-release/git : commetta i seguenti file che sono stati aggiornati dal build Ionic dell'applicazione e dal lavoro di rilascio semantico (package.json, CHANGELOG.md Ecco ios/App/App.xcodeproj/project.pbxproj - Non costruisco per Android, ancora)
• @semantic-release/github : allega il CHANGELOG.md file alla versione Github come risorsa
• @semantic-release/exec: utilizza 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)

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

Costruzione di nuovi binari con XCode Cloud

Integrazione di tutto questo con XCode Cloud per la costruzione di nuove versioni del file binario dell'applicazione è semplice (Non sto ancora distribuendo su Google Play, ma quella costruzione dovrebbe essere simile) :

• Ho configurato un processo XCode Cloud per costruire quando c'è una modifica sul ramo che desidero utilizzare per questo (ad es. production)
• su questo ramo, ho imposto XCode Cloud per costruire solo quando il CHANGELOG.md file viene aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• Posso attivare le 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 desiderassi, potrei distribuire un'applicazione AppStore diversa per ogni applicazione di cliente personalizzata distribuita da una branch di rilascio 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 nel mio pipeline di rilascio semantico standard, rapidamente entro il periodo di prova di 14 giorni, e il risultato è il seguente :

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

Passaggi successivi

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

Spero di aggiungere una verifica di pre-elaborazione migliore dei Capgo bundle upload prerequisiti nella mia configurazione di rilascio semantico.

Ho ora 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, come cliente e utente, 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. Puoi trovarmi su LinkedIn a

https://linkedin.com/in/rbarrow Puoi prendere un'occhiata alle nostre offerte di Salesforce a.

https://www.rapido-companion.app e and https://www.rapido.cloud In fase di sviluppo.