1. Introduzione
At 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 have developed this mobile app on a modern and “standard” platform with widespread components and tools including Ionic 8, Angular 18, TypeScript, Capacitor and now Capgo CapacitorUpdater. These are more simple to handle for clients who do not want to manage Salesforce platform specifics such as Lightning Web Components; and its easier and cheaper for me to recruit developers and maintainers of Ionic + Angular mobile applications.
This article explains my design, my choices and implementation which make Capgo and semantic-release a very successful no-brainer for managing all deployments automatically via Github Actions. All this was designed, tested and documented during the nice 14-day free trial period of Capgo CapacitorUpdater.
2. Why use Capgo ? Why use 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 eroi temevo la curva d'apprendimento per rendere questo progetto un successo, ma riuscii a mettere il mio app su Apple TestFlight con facilità. Poi, ero 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 Capgo CapacitorUpdater mi ha aiutato ad aggiornare il mio'applicazione 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 configurare!
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.
Questa è la mia organizzazione del modello di rami e rilascio
Per ogni applicazione, indipendentemente se mobile, web o Salesforce :
- sviluppo è effettuato su
feature/...rami derivatimain, e sono fusi inmainche è il riferimento per la maggior parte dei rami di sviluppo, fuori dalla manutenzione e dalle funzionalità specifiche per le consegne personalizzate (ne parlerò in seguito) - le rilasci attivano i deployment 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 attivano i deployment da una richiesta di pull che viene fusa in un ramo di deployment. Non utilizzo i deployment attivati dai 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
Un nota a lato su come funziona semantic-release :
In una branca di distribuzione, quando viene attivato semantic-release, 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 alle funzionalità consegnate. Le correzioni creeranno una nuova versione patch, mentre le funzionalità creeranno una nuova versione minore. Includerà anche le versioni prerelease alpha, beta, ecc. nel numero di 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.
Aggiornerà anche tutti i tuoi pull request git (Github, nel mio caso) e le relative issue con commenti che li collegano al tag e alla release. Infine, in questa Github release, attaccherà asset come il codice code, i binari se necessario CHANGELOG.md, ecc.
4. Le branche, le release/prerelease, i 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 propria versione del “Conventional Commits” standard-version tool, con il proprio repo forkato standard-version (https://github.com/Cap-go/standard-version, e le 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 deployemnts (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.
Desidero inoltre che semantic release generi le distribuzioni dell'applicazione su diversi canali.
Come menzionato sopra, ho bisogno di distribuire versioni prerelease da branch come alpha, beta, nightly ecc., ma anche versioni specifiche per i clienti su branch come production-customer-jones, production-customer-doe, ecc.
Capgo fornisce la caratteristica "canali" che è esattamente ciò che anche semantic release supporta, quindi sono entusiasta di farli funzionare insieme. Questo si adatta anche alle diverse costruzioni di branch 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 branch 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 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 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 queste, 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 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
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 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, il rilascio semantico attiverà un'installazione.
Imposta CAPGO_APIKEY in i segreti del tuo repository.
Aggiorna il tuo CAPGO_APPID qui.
La configurazione del rilascio semantico è 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:branchesimpostano la configurazione delle branch (name), mappate al canale Capgo (channel) e come verrà chiamato il numero di versione prerelease (prerelease). Ad esempio, sebranch.prerelease = "development", il numero di versione generato dal rilascio semantico saràx.y.z-development.n- installazioni sul
alphaE ealpha-nocapgole rami deployeranno l'app sul canale, ma con nomi di prerelease diversi nel numero di versionealphao - deployeranno sul canale, ma con nomi di prerelease diversi nel numero di versione
dev-rupertle rami deployeranno sul canale, ma con nomi di prerelease diversi nel numero di versionedev-paulodevelopmentchannel on Capgo, all with the samedevelopmentsu __CAPGO_KEEP_0__, tutti con lo stesso
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: nella prima fase 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ù tardihttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generatorhttps://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formatCHANGELOG.md@semantic-release/git: commetto i seguenti file che sono stati aggiornati dalla build Ionic dell'applicazione e dal lavoro di rilascio semantico (package.json,CHANGELOG.mdeios/App/App.xcodeproj/project.pbxproj- Non costruisco per Android, ancora@semantic-release/github: allego ilCHANGELOG.mdfile al rilascio Github come risorsa@semantic-release/exec: utilizzo questi 2 comandi per preparare la costruzione dell'app (prepareCmd) e poi per costruire e distribuire in modo effettivo 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 una configurazione minimale.
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) :
- Stabilisco un processo XCode Cloud per costruire quando c'è un cambio sulla branch che desidero utilizzare per questo (ad esempio
production) - su questa branch, stabilisco XCode Cloud per costruire solo quando il
CHANGELOG.mdil 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.channelimpostato inreleaserc.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. Conclusione
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
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ò poi un'altra (a pagamento) versione dell'app sullo Store, sotto un altro record, e l'aggiornerei regolarmente con Capgo.
Spero di poter aggiungere una verifica pre-compilazione migliore di Capgo bundle upload nelle mie impostazioni 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 offerta di prodotti Rapido Cloud Troverai me su LinkedIn a
https://linkedin.com/in/rbarrow Potrai prendere un'occhiata alle nostre offerte di Salesforce a.
https://www.rapido-companion.app 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 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.
