How Rapido Cloud manage Semantic Release with 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.

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.

Questo articolo spiega il mio design, le mie scelte e l'implementazione che rendono Capgo e semantic-release una soluzione molto facile e senza problemi per gestire tutti i rilasci 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 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.

I was rather afraid of the learning curve to make this successful but I got my app onto Apple TestFlight quite easily. I was then in position to use Capgo CapacitorUpdater to deploy my updates much faster.

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 !

So Capgo CapacitorUpdater helped me update my application on my mobile, live, 1 minute after saving a new feature or fix in my source code : so relieving, and so flexible, and easy to set up !

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

So now I have my delivery to Capgo servers working correctly, I need to automate this and fit it into my CI/CD pipeline.

Questa è la mia organizzazione del modello di branching e rilascio

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

• si svolge il su feature/... ramificazioni di main, e vengono merge in main che è il riferimento per la maggior parte delle ramificazioni di sviluppo, fuori dalla manutenzione e dalle funzionalità specifiche per le consegne personalizzate (ne parlerò in seguito)
• si attivano le distribuzioni da rami di rilascio che possono essere : production, rami prerelease (alpha, beta, nightly, ecc.) e anche rami specifici per il cliente o contestuali per le consegne personalizzate
• i rilasci sono attivati da una richiesta di pull che viene fatta confluire in un ramo di rilascio. Non utilizzo i rilasci 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/storie/manuelherrera/strategie-di-ramificazione-Git-in-2022

Nota a lato su come funziona semantic-release :

In un ramo di rilascio, 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 patch, mentre le funzionalità creeranno una nuova versione minore. Includerà anche le prerelease automaticamente alpha, betaecc., in versione.

Semantic release 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 semantic release.

Aggiornerebbe inoltre tutti i tuoi pull request git (Github, nel mio caso) e le relative issue con commenti che li collegano alla tag e alla release. Infine, in questa Github release, attaccherà asset come il codice code, i binari se necessario, ecc. CHANGELOG.md4. Ramificazioni, rilasci/prerelease, canali in semantic release e in __CAPGO_KEEP_0__

Quindi cosa voglio che semantic release faccia per Capgo deployment.

So what I want semantic release to do for Capgo deployments is the following.

__CAPGO_KEEP_0__ hanno sviluppato e documentato la propria versione della “Conventional Commits”

Capgo have developed and documented their own version of the “Conventional Commits” standard-version https://__CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (https://github.com/Cap-go/standard-versione i loro capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) anche 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 !)

Quindi è fantastico, e mi è un sollievo perché utilizzo semantic-release estensivamente.

I anche voglio che la rilascio semantico 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-doe, ecc.

Capgo fornisce la caratteristica "canali" che è esattamente ciò che anche la rilascio semantico 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 dalla rilascio semantico 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 e le prerelease della rilascio semantico 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 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 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 Github Actions, è molto semplice. Questo sarà molto simile su altre piattaforme di integrazione continua e distribuzione (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 branchessemantic release attiverà un'implementazione. Impostare CAPGO_APIKEY in i segreti del tuo repository. Aggiorna il tuo CAPGO_APPID qui.

La configurazione del comportamento di semantic release è impostata 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 (namemappate 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
  • implementazioni sul alphae alpha-nocapgo le rami deployeranno l'app sul alphacanale, ma con nomi di prerelease diversi nel numero di versione
  • le distribuzioni sulle ramificazioni dei sviluppatori dev-ruperto dev-paul il canale, ma con lo stesso nome di prerelease nel numero di versione developmentchannel on Capgo, all with the same developmentSpero di aggiungere un controllo di autenticazione per il
• 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 standard 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 .com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format CHANGELOG.md
• @semantic-release/git : genera il file di changelog comepackage.json, CHANGELOG.md Ecco ios/App/App.xcodeproj/project.pbxproj - Non costruisco per Android, ancora)
• @semantic-release/github : aggancia 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 il bundle dell'app al server Capgo (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 tag o rilascio Github, ecc. : tutto è gestito di default da semantic release, con una configurazione minima.

Costruzione di nuovi binari con XCode Cloud

Integrare tutto questo con XCode Cloud per costruire nuove versioni del file binario dell'applicazione è semplice (non sto ancora distribuendo su Google Play, ma quel build dovrebbe essere simile) :

• Il processo XCode Cloud per costruire viene configurato per costruire quando c'è una modifica sulla branca che desidero utilizzare per questo (ad esempio production)
• Il file è aggiornato dopo ogni versione generata da semantic release CHANGELOG.md aggiornamento del file
• 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 poi, se lo desideravo, potevo 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. 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 vengono generati automaticamente da semantic release e sono compatibili con i Capgo server
• semantic release distribuisce automaticamente i bundle di applicazione Capgo, facendo anche uso dei 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, deployerò sicuramente una versione gratuita dell'applicazione sull'AppStore per i test, che verrà aggiornata regolarmente con Capgo durante i test. Deployerò poi un'altra (a pagamento) versione dell'applicazione sull'AppStore, sotto un altro record, e la aggiornerei regolarmente con Capgo.

I spero di aggiungere una verifica pre-compilazione migliore di Capgo bundle upload i 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 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 Salesforce in Francia, prima di intraprendere una nuova avventura come solopreneur Salesforce con il mio offerta di prodotti Rapido Cloud. Potrai trovarmi su LinkedIn a

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

https://www.rapido-companion.app e context: Pagina/Area: Sito web di marketing Capgo. Ruolo: Etichetta breve o elemento di navigazione. Visto in: pagina trust.astro. Chiave messaggio `e` (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 per i dettagli di implementazione in Comportamento dell'aggiornamento, e Tipi di aggiornamento per i dettagli di implementazione in Tipi di aggiornamento.