Come Rapido Cloud gestisce la rilascio semantico con Capgo CapacitorUpdater

1. Introduzione

Presso Rapido Cloud (www.rapido.cloud), sto sviluppando un'applicazione mobile per i clienti di Salesforce per poter facilmente distribuire la propria applicazione mobile personalizzata senza dover passare attraverso i difficili loop di utilizzo della Mobile Salesforce 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 per me è più facile e economico 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 semplice e senza problemi per gestire tutti i deployment automaticamente via Github Actions. Tutta questa cosa è stata progettata, testata e documentata 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 le distribuzioni delle app mobili molto più semplici, rapide e flessibili rispetto al processo di consegna standard Apple AppStore/Google PlayStore. Questa è la mia prima applicazione mobile che sto pubblicando nelle store, avendo concentrato in passato sullo sviluppo di app web, solitamente sviluppate sulla piattaforma Salesforce Experience Cloud.

I eroi un po' spaventato dalla curva di apprendimento per rendere questo progetto riuscito, ma sono riuscito a mettere il mio app su Apple TestFlight con facilità. Sono poi 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 app mobile sul mio telefono, invece di testare in un emulatore di mobile o in un simulatore tramite il browser mobile di Nexus suggerito da IIonic. E' 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 Capacitor app mobile, non ero sicuro se tutto sarebbe andato a buon fine : nulla di meglio che testare l'app reale, in condizioni reali!

Quindi Capgo CapacitorUpdater mi ha aiutato ad aggiornare il mio applicativo sul mio 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

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

Ecco come organizzo il mio modello di rami e rilascio

Per ogni applicazione, indipendentemente se mobile, web o Salesforce :

• si svolge il si stacca da feature/... , e vengono fuse in mainche è il riferimento per la maggior parte dei rami di sviluppo, fuori dalla manutenzione e dalle funzionalità specifiche per le consegne personalizzate (ne saprai di più in seguito) main sviluppo
• deployimenti sono attivati da rami di rilascio che possono essere : production, rami prerelease (alpha, beta, nightly, ecc.) e anche rami specifici per il cliente o contestuali per consegne personalizzate
• deployimenti sono attivati da una richiesta di pull che viene incorporata in un rama di deployment. Non utilizzo deployment attivati da 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/stories/manuelherrera/git-branching-strategies-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 alle correzioni o funzionalità consegnate. alpha, betaIl 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 nel rilascio semantico.Inoltre, aggiornerebbe tutti i tuoi pull request di merge e relative issue con commenti che li collegano al tag e al rilascio. Infine, in questo rilascio __CAPGO_KEEP_1__, attaccherà asset come il codice __CAPGO_KEEP_2__, i binari se necessario, etc.

It will also update all your git (Github, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this Github release, it will attach assets such as source code, binaries if necessary, CHANGELOG.mdQuindi, cosa voglio che semantic release faccia per i rilasci __CAPGO_KEEP_0__ è quanto segue.

4. Branches, releases/prereleases, channels in semantic release and in Capgo

Capgo hanno sviluppato e documentato la loro versione del “Conventional Commits”

tool, con il loro fork del repository

Capgo hanno sviluppato e documentato la loro versione del “Conventional Commits” standard-version tool, 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-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/). I bundle JavaScript seguono la 'standard' semver 'Semantic Versioning' (https://semver.org) che semantic-release anche segue (ovviamente !)

Quindi è tutto a posto, e mi è un grande sollievo perché utilizzo semantic-release estensivamente.

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. Questo si adatta 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 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 e i prerelease di semantic release 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 a Capgo, è necessario utilizzare il comando Capgo CLI bundle upload. Digita npx @capgo/cli@latest bundle upload --help To ottenere le numerose opzioni di caricamento. Tra queste, useremo le seguenti :

npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID

• CANALE è il Capgo canale a cui vogliamo distribuire (ad esempio alpha)
• 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_IDAPP è 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

L'automazione del rilascio semantico con Github Actions

La bellezza di semantic release è che l'automazione del rilascio, 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 semantic release.

For ogni merge su una branca elencata in branches, semantic release attiverà un'installazione. Imposta CAPGO_APIKEY nel segreti del tuo repository. Aggiorna il tuo CAPGO_APPID qui.

Il comportamento di semantic release è 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 semantic release sarà x.y.z-development.n
  • installazioni sul alphae le alpha-nocapgo le diramazioni si distribuiranno entrambe l'applicazione sul alphacanale, ma con nomi di prerelease diversi nel numero di versione
  • le distribuzioni alle diramazioni dello sviluppatore dev-ruperto dev-paul si distribuiranno 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 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 : generare 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 : allega il ios/App/App.xcodeproj/project.pbxproj file al rilascio __CAPGO_KEEP_0__ come risorsa
• @semantic-release/github : utilizza questi 2 comandi per preparare il build dell'app ( CHANGELOG.md ) e poi per effettuare il build e distribuire il bundle dell'app sulle Github server (
• @semantic-release/execSi noterà che non ci sono spiegazioni su come vogliamo che il numero di versione venga calcolato e incrementato, come dobbiamo generare un changelog, un __CAPGO_KEEP_0__ tag o rilascio, ecc. : tutto è gestito di default da semantic release, con una configurazione minima.prepareCmd) and then to effectively build deploy the app bundle to the Capgo servers (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.

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

su questa branca, ho imposto XCode Cloud per costruire solo quando il

• file è stato modificato production)
• e non ci sono altre modifiche da costruire CHANGELOG.md il file è aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• Posso attivare 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 release branch personalizzata, come menzionato in precedenza.

Costruzione di binari di app su XCode Cloud con Capgo canali

7. Conclusioni

In conclusione, sono molto felice di aver potuto integrare Capgo CapacitorUpdater nella mia pipeline di rilascio semantico standard, rapidamente entro il ritardo del periodo di prova di 14 giorni, e il risultato è il seguente:

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

Passaggi successivi

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

Spero di poter aggiungere una verifica pre-compilazione migliore di Capgo bundle upload le precondizioni 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 di 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 di successo di Salesforce SI in Francia, prima di partire per una nuova avventura come Salesforce solopreneur con il mio Rapido Cloud offerta di prodotti.

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

Potrai 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 Semantic Release con Capgo CapacitorUpdater

Se stai utilizzando Come Rapido Cloud gestisce Semantic Release con Capgo CapacitorUpdater per pianificare la consegna di aggiornamenti in tempo reale, connettilo con Capgo Live Updates per il flusso di lavoro del prodotto in Capgo Live Updates, Panoramica per i dettagli di implementazione in Panoramica, Caratteristiche per i dettagli di implementazione in Features, Comportamento di Aggiornamento per i dettagli di implementazione in Comportamento di Aggiornamento, e Tipi di Aggiornamento per i dettagli di implementazione in Tipi di Aggiornamento.