How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

1. Introduzione

Presso 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 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 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 un vero e proprio no-brainer per la gestione di tutti i deployment automatici via 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 delle app mobili molto più semplici, molto più rapidi e flessibili rispetto al processo di consegna standard Apple AppStore/Google PlayStore.

Sono stato piuttosto spaventato dalla curva di apprendimento per renderlo questo, ma sono riuscito a mettere la mia app su Apple TestFlight con facilità. Sono poi stato 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 !

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.

Questo è come organizzo il mio modello di branching e rilascio

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

• si svolge il su feature/... rami che si staccano main, e vengono fuse 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 dai rami da rami di rilascio che possono essere : production, rami di rilascio prerelease (alpha, beta, nightly, ecc.) e anche rami specifici per i clienti 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 di patch, mentre le funzionalità creeranno una nuova versione minore. Includerà anche le versioni prerelease automaticamente alpha, betaecc., ecc. nella versione del numero.

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 nella rilascio semantico.

Aggiungerà inoltre 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 fonti code, binari se necessario, ecc. CHANGELOG.md4. Ramificazioni, rilasci/prerilasci, canali nella rilascio semantico e in __CAPGO_KEEP_0__

Quindi cosa voglio che la rilascio semantico faccia per i 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-versionanche capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionrepos. Hanno documentato sul loro blog lo schema di versione utilizzato da Capgo nei loro deployemnts (https://capgo.app/blog/how-version-work-in-capgo/). I bundle JavaScript seguono la "standard" semver "Semantic Versioning" (https://semver.orgche semantic-release anche segue (ovviamente !)

Quindi è fantastico, e mi è un grande sollievo perché utilizzo semantic-release in modo estensivo.

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

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 dei “canali” che è esattamente ciò che anche la rilascio semantico supporta, 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 sotto).

I numeri di versione semver generati dalla rilascio semantico sui prerelease hanno l'aspetto di 1.0.0-alpha.1Successivi costruzioni su questo ramo incrementeranno il numero di costruzione a 1.0.0-alpha.2, ecc. Anche se non sono documentati esplicitamente, questi numeri di versione sono supportati da Capgo, che è una notizia meravigliosa per me: utilizzerò i canali e i 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 esempio alpha)
• LA 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 integrazione continua e distribuzione continua (login
• CAPGO_APPID è 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

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 continua.

# ./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 branchesLa rilascio semantico attiverà un deployment. CAPGO_APIKEY impostare CAPGO_APPID In segreto del tuo repository.

aggiornare il tuo .releaserc.json Ecco.

// .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:prereleaseconfigura le branche ( branch.prerelease = "development"e mappa il canale ( x.y.z-development.n
  • e come verrà chiamato il numero di versione prerelease ( alphaad esempio se si vuole che il numero di versione generato dalla rilascio semantico sia il numero di versione del canale ( alpha-nocapgo le brancheranno entrambe sul canale, ma con nomi di prerelease diversi nel numero di versione alphama con nomi di prerelease diversi nel numero di versione
  • le deployeranno sul canale dev-ruperto dev-paul saranno entrambe deployate sul canale, ma con lo stesso nome di prerelease nel numero di versione developmentsu Capgo, tutte con lo stesso nome di prerelease nel numero di versione developmentin fase iniziale di rilascio semantico, controlla se ha l'accesso corretto a __CAPGO_KEEP_0__. Spero di poter aggiungere un controllo di autenticazione per il __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ qui più avanti
• 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 https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formathttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator : commetta i seguenti file che sono stati aggiornati dal build Ionic dell'applicazione e dal lavoro di rilascio semantico ( CHANGELOG.md
• @semantic-release/git opackage.json, CHANGELOG.md e ios/App/App.xcodeproj/project.pbxproj - Non costruisco per Android, ancora)
• @semantic-release/github : attacca il CHANGELOG.md file to the Github release as an asset
• @semantic-release/exec: utilizza questi 2 comandi per preparare la costruzione dell'app (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.

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) :

• Imposto un processo XCode Cloud per costruire quando c'è una modifica sulla branch che desidero utilizzare per questo (ad esempio production)
• su questa branch, imposto XCode Cloud a costruire solo quando il CHANGELOG.md file viene aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic release
• I 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 una variabile di ambiente manualmente 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 periodo di prova di 14 giorni, e il risultato è il seguente:

• i numeri di versione dei bundle vengono generati automaticamente da rilascio semantico e sono compatibili con i Capgo server
• rilascio semantico 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, sarò sicuramente in grado di distribuire una versione gratuita dell'applicazione sul AppStore per i test, che verrà aggiornata regolarmente con Capgo durante i test. Poi distribuirò un'altra (a pagamento) versione dell'applicazione sul 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 di navigazione breve o elemento UI. 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.