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.

I ho avuto lo sviluppo di 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 meno costoso 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 una scelta molto facile e senza rischi per gestire tutti i deployment automaticamente via 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 di consegna standard Apple AppStore/Google PlayStore. Questa è la mia prima app mobile che sto pubblicando nelle store, essendo concentrato in passato su app web, solitamente sviluppate sulla piattaforma Salesforce Experience Cloud.

Ero piuttosto spaventato dalla curva di apprendimento per rendere questo progetto riuscito ma sono riuscito a pubblicare la mia app su Apple TestFlight con facilità. Ero poi 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 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

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 se 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 sapremo di più in seguito)
• i rilasci vengono attivati Dal rilascio delle branch che possono 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 essendo incorporati in una branch 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 - fonte https://faun.dev/c/storie/manuelherrera/schemi-di-branching-in-2022

Nota a lato su come funziona semantic-release :

In una branch di distribuzione, quando semantic-release viene attivato, calcolerà automaticamente il nuovo numero di versione su questa branch, in base al numero di versione del tag precedente sulla branch e ai fissaggi o alle funzionalità consegnati. I fissaggi creeranno una nuova versione 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 al tag e alla release. Infine, in questa Github release, attaccherà asset come fonti code, eseguibili se necessario, CHANGELOG.mdecc.

4. Branches, releases/prereleases, canali in semantic release e in Capgo

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

Voglio che semantic release 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), e le loro proprie capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) anche così 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 deployment (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ì è bello, e mi è un sollievo perché utilizzo semantic-release estensivamente.

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 funzionalità dei “canali” che è esattamente ciò che semantic release supporta anche, quindi sono entusiasta di farli funzionare insieme. Queste si adattano anche alle diverse costruzioni di rami gestite da XCode Cloud (vedi di più su questo sotto).

Il numero di versione Semver generato da semantic release sui 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, 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 es. alpha)
• LA VERSIONE è generata da semantic release (ad es. 1.0.0-alpha.1)
• CAPGO_APIKEY è fornito da Capgo per identificare in modo univoco la tua pipeline di CI/CD di accesso
• CAPGO_APPID è fornito da Capgo per identificare in modo univoco la tua applicazione (ad es. 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

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 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 solo l'ambiente NodeJS, quindi chiama il rilascio semantico.

Per ogni mazzo 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 ( x.y.z-development.n
  • ) e come verrà chiamato il numero di versione prerelease ( alpha). Ad esempio, se ( alpha-nocapgo le branche deployeranno l'app sul alphacanale, ma con nomi di prerelease diversi nel numero di versione
  • le distribuzioni sulle branche 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 e ios/App/App.xcodeproj/project.pbxproj - Non costruisco per Android, ancora)
• @semantic-release/github : incolla 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 sulla versione del numero da calcolare e incrementare, 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 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 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 desideravo, potevo 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 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ò disponibile rapidamente ai tester attraverso TestFlight (per iOS). Considerando la potenza di Capgo, sicuramente deployerò una versione gratuita dell'applicazione sull'AppStore per i test, che verrà aggiornata regolarmente con Capgo durante i test. Poi deployerò un'altra (a pagamento) versione dell'applicazione sull'AppStore, sotto un altro record, e anche aggiornerei quella regolarmente con Capgo.

Spero di aggiungere una verifica pre-compilazione migliore di 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 Salesforce solopreneur con il mio offerta di prodotto 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).

Continua da come Rapido Cloud gestisce il rilascio semantico con Capgo CapacitorUpdater

Se stai utilizzando Come Rapido Cloud gestisce il 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, Aggiorna il comportamento per il dettaglio di implementazione in Aggiorna il comportamento, e Tipi di Aggiornamento per il dettaglio di implementazione in Tipi di Aggiornamento.