Come Rapido Cloud gestisce la rilascio semantico con 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.

Questa pubblicazione spiega il mio design, le mie scelte e l'implementazione che rendono Capgo e semantic-release un vero e proprio no-brainer per la gestione di tutti i rilasci automaticamente tramite Github Actions. Tutti questi sono stati progettati, testati e documentati durante il periodo di prova gratuita di 14 giorni di Capgo CapacitorUpdater.

2. Perché utilizzare Capgo ? Perché utilizzare 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.

Mi sono sentito un po' spaventato dalla curva di apprendimento per rendere questo riuscito, ma sono riuscito a caricare il mio app su Apple TestFlight con facilità. Sono quindi stato in grado di utilizzare Capgo CapacitorUpdater per distribuire le mie aggiornamenti molto più velocemente.

La mia prima richiesta e caso di test era di distribuire per me stesso per testare il mio app come una vera applicazione 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'applicazione mobile Capacitor, non ero sicuro se tutto sarebbe andato a buon fine: nulla di meglio che testare l'app reale, in condizioni reali !

Così Capgo CapacitorUpdater mi ha aiutato ad aggiornare la mia applicazione sul mio dispositivo mobile, in tempo reale, 1 minuto dopo aver salvato una nuova funzione o correzione nel mio codice code : così rilassante, e così flessibile, e facile da impostare!

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

Così ora ho il mio invio a Capgo server che funziona correttamente, ho bisogno di automatizzarlo e inserirlo nel mio pipeline CI/CD.

Questo è come organizzo il mio modello di rami e rilascio

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

• la sviluppo viene eseguito su feature/... rami derivati main, e vengono fusi in main che è il riferimento per la maggior parte dei rami di sviluppo, fuori dalla manutenzione e dalle funzionalità specifiche per le consegne personalizzate (ne sapremo di più in seguito)
• le consegne sono attivate da rami di rilascio potrebbe essere : production, rami di pre-uscita (alpha, beta, nightlye anche branch specifiche per clienti o contesti per consegne personalizzate
• le distribuzioni sono attivate da una richiesta di pull Non utilizzo i rilasci triggerati dai tag perché semantic release gestisce i tag e tutto il resto per me.

Di base, si tratta del flusso Gitlab :

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

Nota a lato su come funziona semantic-release :

In un ramo di distribuzione, quando semantic-release viene attivato, calcolerà automaticamente il nuovo numero di versione su questo ramo, in base al numero di versione del tag precedente sul ramo e alle correzioni o alle funzionalità consegnate. Le correzioni creeranno una nuova versione di patch, mentre le funzionalità creeranno una nuova versione minore. Includerà anche automaticamente il prerelease alpha, beta, ecc. nel numero di versione.

La rilascio semantico genera il changelog dai tuoi commit, raggruppando le correzioni e le funzionalità come definite nei commit convenzionali (vedi https://www.conventionalcommits.org/en/about) e configurati in rilascio semantico.

Aggiornera anche tutti i tuoi pull request git (Github, nel mio caso) e relative issue con commenti che li collegano alla tag e al rilascio. Infine, in questo Github rilascio, attaccherà asset come fonti code, binari se necessario, CHANGELOG.md, ecc.

4. Ramificazioni, rilasci/prerelease, canali in rilascio semantico e in Capgo

Quindi cosa voglio che rilascio semantico faccia per i Capgo deployment.

Voglio che rilascio semantico 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), and their own capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) as well as 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 deploy (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 estensivamente.

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

As 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-doe, ecc.

Capgo fornisce 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 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 rama incrementeranno il numero di costruzione a 1.0.0-alpha.2, ecc. Anche se non è documentato esplicitamente, questi numeri di versione sono supportati da Capgo, 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 la distribuzione dei pacchetti della tua app su Capgo, devi utilizzare il comando Capgo CLI bundle upload. Digita npx @capgo/cli@latest bundle upload --help per ottenere le numerose opzioni di caricamento. Tra quelle, 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)
• La versione è generata da semantic release (ad es. 1.0.0-alpha.1)
• CAPGO_APIKEY viene fornito da Capgo per identificare in modo univoco il tuo pipeline di login CI/CD
• CAPGO_APPID è fornito da Capgo per identificare in modo univoco il tuo'applicazione (ad es. com.mystartup.mysuperapp)

6. La mia configurazione di rilascio semantico + Capgo CapacitorUpdate

Infine, come si abbinano tutte queste cose?

Le versioni dei pacchetti 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 di Github Actions, è molto semplice. Questo assomiglia molto ad altri 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 semplicemente l'ambiente NodeJS, poi chiama semantic release.

Per ogni merge su una branca elencata in branchessemantic release attiverà una distribuzione. Imposta CAPGO_APIKEY Inserisci i segreti del tuo repository. Aggiorna il tuo CAPGO_APPID Ecco.

Il comportamento della rilascio semantico è impostato 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 imposta la configurazione delle branch (name), mappato sul canale Capgo.channel) e come verrà chiamato il numero di versione prerelease ( ). Ad esempio, seprereleasePer esempio, se branch.prerelease = "development"La versione numero generata da semantic release sarà x.y.z-development.n
  • deployimenti sul alphaand alpha-nocapgo rami branch e la branch di sviluppo deployeranno l'app sul alphacanale, ma con nomi di prerelease diversi nel numero di versione
  • le distribuzioni sulle branch dei sviluppatori dev-ruperto dev-paul deployeranno entrambi sul developmentcanale su Capgo, tutti con lo stesso developmentcanale su __CAPGO_KEEP_0__, tutti con lo stesso
• 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 : standardi rilasci semantic - vedi la loro documentazione (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#formato-del-messaggio-di-commit)
• @semantic-release/release-notes-generator https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format CHANGELOG.md
• @semantic-release/git : commetto i seguenti file che sono stati aggiornati dal build Ionic dell'applicazione e dal lavoro di rilascio semantico ("package.json, CHANGELOG.md and ios/App/App.xcodeproj/project.pbxproj - Non costruisco per Android, ancora)
• @semantic-release/github : attacca il file alla __CAPGO_KEEP_0__ rilascio come risorsa CHANGELOG.md file al rilascio Github come risorsa
• @semantic-release/execUsa questi 2 comandi per preparare la build dell'app.prepareCmdEcco come costruire e distribuire l'app bundle sui server Capgo successivamente.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.

Costruisco nuovi binari con XCode Cloud

Configuro un processo XCode Cloud per costruire quando c'è una modifica sulla branca che desidero utilizzare per questo (ad esempio

• Imposto un processo XCode Cloud per costruire quando c'è un cambiamento sulla branca che desidero utilizzare per questo (ad esempio production)
• sulla questa branch, imposto XCode Cloud per costruire solo quando CHANGELOG.md il file viene aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• I can trigger builds on different branches to simulate the deployment for different channels. In each configuration of XCode Cloud build on a different branch, I set an environment variable manually with the value of 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 di cliente personalizzata distribuita da una branca di rilascio personalizzata, come menzionato in precedenza.

Costruzione di binari di app con XCode Cloud con canali Capgo

7. Conclusioni

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 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 canali Capgo
• questo si adatta bene alle costruzioni di binari di app di XCode Cloud

Next steps

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

Spero di aggiungere una verifica pre-costruzione migliore di Capgo bundle upload prerequisiti nella mia configurazione 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 in 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 solopreneur di Salesforce con il mio Rapido Cloud offerta di prodotti.

Potrai trovarmi su LinkedIn a https://linkedin.com/in/rbarrow.

Potrai prendere uno sguardo alle nostre offerte di 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 Capgo CapacitorUpdater

Se stai utilizzando Come Rapido Cloud gestisce la rilascio semantico con Capgo CapacitorUpdater per pianificare il live update rilascio, connettilo con Capgo Aggiornamenti in Tempo Reale per il workflow del prodotto in Capgo Live Update, 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 Update Behavior, e Tipi di Aggiornamento per i dettagli di implementazione in Tipi di Aggiornamento.