How Rapido Cloud gestisce Semantic Release con Capgo CapacitorUpdater

1. Introduzione

A 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 loop di utilizzo della piattaforma Salesforce Mobile SDK o del Salesforce Mobile Publisher.

Ho sviluppato questa app mobile su una piattaforma moderna e “standard” con componenti e strumenti ampiamente 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 è più facile e economico per me reclutare sviluppatori e mantenitori di applicazioni mobili Ionic + Angular.

Questo articolo spiega il mio design, le mie scelte e l'implementazione che rendono Capgo e semantic-release un vero successo senza sforzo per gestire tutti i deployment 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 mi ha attirato con la sua promessa di rendere i deployment degli app mobili molto più semplici, molto più rapidi e flessibili rispetto al processo di consegna standard di Apple AppStore/Google PlayStore. Questa è la mia prima applicazione mobile che sto pubblicando nelle store, essendo concentrato in passato su app web, solitamente sviluppate su Salesforce Experience Cloud.

Ero piuttosto preoccupato della curva di apprendimento per rendere questo successo ma sono riuscito a caricare il mio app su Apple TestFlight con facilità. Ero quindi in grado di utilizzare Capgo CapacitorUpdater per distribuire le mie aggiornamenti molto più velocemente.

Il mio primo requisito e caso di test era quello di 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. Non avendo l'esperienza passata di testare una Capacitor app mobile, non ero sicuro se tutto sarebbe andato a buon fine : nulla meglio che testare l'app reale, in condizioni reali !

So 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 nella mia sorgente code : così rilassante, e così flessibile, e facile da impostare !

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

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

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

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

• lo sviluppo viene effettuato 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 sapremo di più in seguito)
• le distribuzioni sono attivate da branch di rilascio che potrebbe essere : production, rami prerelease (alpha, beta, nightly, ecc.) e anche rami specifici per il cliente o contestuali per consegne personalizzate
• le distribuzioni sono attivate da una richiesta di pull le distribuzioni sono attivate da una richiesta di pull. Non utilizzo le distribuzioni attivate da 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/stories/manuelherrera/git-branching-strategies-in-2022

Nota a margine 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. Inoltre, include 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 definito nei commit convenzionali (vedi https://www.conventionalcommits.org/en/about) e configurato nella rilascio semantico.

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

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

Quindi cosa voglio che la rilascio semantico faccia per i Capgo deployment è quanto segue.

Voglio che la rilascio semantico 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-version), e la loro propria capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versione non solo capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionrepository. Hanno documentato sul loro blog lo schema di versione utilizzato da Capgo nei loro deployment (https://capgo.app/blog/how-version-work-in-capgo/)Il bundle JavaScript segue la 'standard' semver 'Semantic Versioning' (https://semver.org semantic-release ) che

anche segue (ovviamente !) semantic-release Quindi è fantastico, e mi è un grande sollievo perché utilizzo

estensivamente e con regolarità. Inoltre, desidero che semantic release generi le distribuzioni delle applicazioni 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 dei “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 ha l'aspetto di 1.0.0-alpha.1. Le costruzioni successive su questo ramo 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, il che è una notizia meravigliosa per me: utilizzerò i canali di semantic release 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. Tipo 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 è fornito da Capgo per identificare in modo univoco il tuo pipeline di integrazione continua e distribuzione (CI/CD) di accesso
• CAPGO_APPID è fornito da Capgo per identificare in modo univoco il tuo'applicazione (ad es. com.mystartup.mysuperapp)

6. La configurazione di semantic release + Capgo CapacitorUpdate

Infine, come si abbinano tutte queste cose?

Il bundle dell'applicazione costruito con semantic release e Github Actions

L'automazione della rilascio semantic con Github Actions

La bellezza di semantic release è che l'automazione del rilascio, nella forma di un flusso di lavoro di Github Actions, è molto semplice. Questo assomiglia molto ad altri platform 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 semantic release.

Per ogni merge su una branca elencata in branches, semantic release attiverà un rilascio. Impostare CAPGO_APIKEY In repository segreti. Aggiorna il tuo CAPGO_APPID Ecco.

Il comportamento di 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), 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 da rilascio semantico sarà x.y.z-development.n
  • deployments al alphae le alpha-nocapgo rami deployeranno entrambi l'app sul alphacanale, ma con nomi prerelease diversi nel numero di versione
  • deployamenti ai rami del developer dev-ruperto dev-paul si deployeranno entrambi al developmentcanale su Capgo, tutti con lo stesso developmentparola chiave prerelease nel numero di versione
• verifyConditions : nella prima fase di rilascio semantico, controlla di avere l'accesso corretto a Github. Spero di aggiungere un controllo di autenticazione per il Capgo CLI qui più avanti
• @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 e ios/App/App.xcodeproj/project.pbxproj - Non costruisco per Android, ancora)
• @semantic-release/github : attacca il CHANGELOG.md file al rilascio Github come risorsa
• @semantic-release/exec: utilizza questi 2 comandi per preparare la costruzione dell'app (prepareCmd) e poi per costruire e distribuire effettivamente il bundle dell'app sulle Capgo server (publishCmd)

Si noterà 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 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 esempio production)
• su questo ramo, ho impostato XCode Cloud per costruire solo quando il CHANGELOG.md file viene aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• Posso attivare costruzioni su rami diversi per simulare la distribuzione per canali diversi. In ogni configurazione di costruzione di XCode Cloud su un ramo diverso, 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 volevo, potrei distribuire una diversa applicazione AppStore per ogni applicazione di rete personalizzata distribuita da una branca di rilascio personalizzata, come menzionato in precedenza.

Costruzione di binari di app su XCode Cloud con canali Capgo

7. Conclusioni

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 pacchetti sono generati automaticamente da semantic release e sono compatibili con i server Capgo
• semantic release distribuisce automaticamente i pacchetti di applicazione Capgo, facendo anche uso dei canali Capgo
• questo si adatta bene alle costruzioni di binari di app su XCode Cloud

Passaggi successivi

Mi trovo 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 sul AppStore per i test, che verrà aggiornata regolarmente con Capgo durante i test. Poi distribuirò un'altra (pagata) versione dell'app sul AppStore, sotto un altro record, e anche aggiornerei regolarmente quella con Capgo.

Spero di aggiungere una verifica pre-costruzione migliore di Capgo bundle upload I ho preso in considerazione i prerequisiti nella mia configurazione di rilascio semantico.

Ora ho una pipeline di rilascio semantico pulita, 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 di Salesforce in Francia, prima di intraprendere una nuova avventura come solopreneur di Salesforce con il mio Rapido Cloud offerta di prodotti.

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

Potete prendere un'occhiata 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 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 For l'implementazione dettagliata in Update Behavior, e Tipi di Aggiornamento Per l'implementazione dettagliata in Tipi di Aggiornamento.