1. Introduzione
In Rapido Cloud (www.rapido.cloud), sto sviluppando un'app mobile per i clienti Salesforce per distribuire facilmente la propria app mobile brandizzata senza dover affrontare i complessi passaggi per usare Salesforce Mobile SDK o Salesforce Mobile Publisher.
Ho sviluppato questa app mobile su una piattaforma moderna e "standard", con componenti e strumenti ampiamente diffusi come Ionic 8, Angular 18, TypeScript, Capacitor e ora Capgo CapacitorUpdater. Questi sono più semplici da gestire per i clienti che non vogliono occuparsi delle specificità della piattaforma Salesforce, come i Lightning Web Components; inoltre, per me è più facile ed economico reclutare sviluppatori e manutentori di applicazioni mobile Ionic + Angular.
Questo articolo spiega il mio design, le mie scelte e l'implementazione che rendono Capgo e semantic-release una soluzione semplicissima e vincente per gestire tutti i deployment automaticamente tramite Github Actions. Tutto è stato progettato, testato e documentato durante il periodo di prova gratuita di 14 giorni di Capgo CapacitorUpdater.
2. Perché usare Capgo? Perché usare semantic-release?
Capgo CapacitorUpdater mi ha colpito con la promessa di rendere i deployment delle app mobile molto più semplici, rapidi e flessibili rispetto al processo standard di Apple AppStore/Google PlayStore. Questa è la mia prima applicazione mobile che pubblico sugli store, dopo essermi concentrato in passato sulle web app, solitamente sviluppate su Salesforce Experience Cloud.
Temevo un po' la curva di apprendimento per farcela, ma sono riuscito a caricare la mia app su Apple TestFlight piuttosto facilmente. A quel punto, ho potuto usare Capgo CapacitorUpdater per distribuire i miei update molto più velocemente.
Il mio primo requisito e caso di test era quello di fare il deploy per me stesso, così da testare la mia app come una vera app mobile sul mio telefono, invece di usare un emulatore o un simulatore tramite il browser mobile Nexus suggerito da Ionic. Questo perché la mia app utilizza feature native come la Geolocation o l'accesso alla Galleria Foto e alla Camera. Non avendo esperienza nel testare una Capacitor mobile app, non ero sicuro che tutto funzionasse correttamente: non c'è niente di meglio che testare l'app reale, in condizioni reali!
Così Capgo CapacitorUpdater mi ha aiutato ad aggiornare la mia applicazione sul mobile, in live, un minuto dopo aver salvato una nuova feature o un fix nel mio code : è stato un sollievo, ed è estremamente flessibile e facile da configurare!
3. Il mio modello di branching e release, e come si integra semantic-release
Ora che il mio delivery verso i server Capgo funziona correttamente, devo automatizzare il tutto e integrarlo nella mia pipeline CI/CD.
Ecco come organizzo il mio modello di branching e release
Per ogni applicazione, che sia mobile, web o Salesforce:
- lo sviluppo viene eseguito su
feature/...branch derivati damain, e vengono mergeati inmainche è il riferimento per la maggior parte dei branch di sviluppo, escludendo la manutenzione e le feature specifiche per delivery custom (maggiori dettagli sotto) - i deployment vengono triggerati dai branch di release che possono essere:
production, branch di prerelease (alpha,beta,nightly, ecc.) e anche branch specifici per cliente o per contesto per consegne custom - i deployment vengono attivati da una pull request che viene mergeata in un branch di deployment. Non uso deployment basati su tag perché semantic-release gestisce i tag e tutto il resto per me.
In pratica, questo è il Gitlab Flow:
Gitlab Flow - sorgente https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Una nota su come funziona semantic-release:
In un branch di deployment, quando viene attivato semantic-release, calcolerà automaticamente il nuovo numero di versione su questo branch, in base alla versione del tag precedente e ai fix o alle feature rilasciate. I fix creeranno una nuova patch version, mentre le feature creeranno una nuova minor version. Include anche automaticamente la prerelease alpha, beta, ecc. nel numero di versione.
Semantic release genera il changelog dai tuoi commit, raggruppando fix e feature come definito nei conventional commits (vedi https://www.conventionalcommits.org/it/about) e configurato in semantic release.
Aggiornerà anche tutte le pull request mergeate su git (Github, nel mio caso) e le relative issue con commenti che le collegano al tag e al release. Infine, in questa release Github, attaccherà asset come il codice sorgente code, i binari se necessari, CHANGELOG.md, ecc.
4. Branch, release/prerelease, channel in semantic release e in Capgo
Quindi, ecco cosa voglio che faccia semantic release per i deployment su Capgo.
Voglio che semantic release generi il numero di versione
Capgo hanno sviluppato e documentato la propria versione di “Conventional Commits” standard-version tool, con il loro repo forkato standard-version (https://github.com/Cap-go/standard-version), e i propri capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) oltre a capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repo. Hanno documentato sul loro blog lo schema di versionamento usato da Capgo nei loro deploy (https://capgo.app/blog/come-funziona-il-versionamento-in-capgo/). I bundle JavaScript seguono il semver “standard” (“Semantic Versioning” (https://semver.org) che semantic-release segue anch'esso (ovviamente!)
Tutto questo è ottimo e un sollievo per me, dato che uso semantic-release ampiamente.
Voglio anche che semantic release generi i deployment dell'app su channel diversi
Come detto sopra, devo deployare 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 offre la funzionalità “channels”, che è esattamente ciò che supporta anche semantic release, quindi sono entusiasta di farli lavorare insieme. Questi si integrano bene anche con le diverse build dei branch gestite da XCode Cloud (maggiori dettagli qui sotto).
I numeri di versione Semver generati da semantic release sulle prerelease sono simili a 1.0.0-alpha.1. Le build successive su questo branch incrementeranno il build number a 1.0.0-alpha.2, ecc. Anche se non è documentato esplicitamente, questi numeri di versione sono supportati da Capgo, il che è un'ottima notizia per me: userò i channel di semantic release e le prerelease per generare le versioni della mia app con i channel di Capgo.
5. Come posso usare Capgo per rilasciare la mia app?
Per automatizzare il deployment dei bundle della tua app su Capgo, devi usare il comando Capgo CLI bundle upload. Digita npx @capgo/cli@latest bundle upload --help per visualizzare le numerose opzioni di upload. Tra queste, useremo le seguenti:
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL è il canale Capgo su cui vogliamo fare il deploy (es.
alpha) - VERSION è generata da semantic release (es.
1.0.0-alpha.1) - CAPGO_APIKEY è fornita da Capgo per identificare univocamente il login della tua pipeline CI/CD
- CAPGO_APPID è fornita da Capgo per identificare univocamente la tua applicazione (es.
com.mystartup.mysuperapp)
6. Il mio setup semantic release + Capgo CapacitorUpdate
Infine, come si incastra tutto questo?
Versioni dell'app bundle buildate con semantic release e Github Actions
Automazione semantic release con Github Actions
Il bello di semantic release è che l'automazione del deploy, tramite un workflow Github Action, è semplicissima. Sarà molto simile su altre piattaforme 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 semplicemente l'ambiente NodeJS e poi chiama semantic release.
Per ogni merge su un branch elencato in branches, semantic release avvierà un deployment.
Imposta CAPGO_APIKEY nei secret del tuo repository.
Aggiorna il tuo CAPGO_APPID qui.
Il comportamento di semantic release è definito nel suo .releaserc.json file di configurazione.
Ecco le mie impostazioni, spiegate qui sotto:
// .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:branchesimposta la configurazione dei branch (name), mappati al canale Capgo (channel) e come verrà chiamato il numero della versione prerelease (prerelease). Ad esempio, sebranch.prerelease = "development", il numero di versione generato da semantic release saràx.y.z-development.n- i deployment su
alphaealpha-nocapgoentrambi i branch deployeranno l'app sulalphachannel, ma con diversi nomi prerelease nel numero di versione - deploy sui branch di sviluppo
dev-rupertodev-paulentrambi deployeranno suldevelopmentchannel su Capgo, tutti con lo stessodevelopmentkeyword prerelease nel numero di versione
verifyConditions: nella prima fase di semantic release, verifica di avere l'accesso corretto a Github. Spero di aggiungere un controllo di autenticazione per Capgo CLI qui più avanti@semantic-release/commit-analyzer: gestione standard di semantic release - 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 changelog comeCHANGELOG.md@semantic-release/gitcommit i seguenti file aggiornati dalla build Ionic dell'applicazione e dal processo di semantic release (package.json,CHANGELOG.mdeios/App/App.xcodeproj/project.pbxproj- Non faccio ancora build per Android)@semantic-release/github: allega ilCHANGELOG.mdfile alla release di Github come asset@semantic-release/exec: usa questi 2 comandi per preparare la build dell'app (prepareCmd) e poi per buildare e deployare effettivamente il bundle dell'app sui server di Capgo (publishCmd)
Noterai che non c'è bisogno di impazzire a spiegare come calcolare e incrementare il numero di versione, come generare un changelog, un tag o una release di Github, ecc.: tutto è gestito di default da semantic-release con una configurazione minima.
Creare nuovi binari con XCode Cloud
Integrare tutto questo con XCode Cloud per buildare nuove versioni del binario dell'app è semplice (non sto ancora deployando su Google Play, ma la build dovrebbe essere simile):
- Ho configurato un processo XCode Cloud per avviare il build quando viene rilevata una modifica sul branch che intendo utilizzare per questo (es.
production) - su questo branch, ho impostato XCode Cloud per buildare solo quando il
CHANGELOG.mdfile viene aggiornato. Questo viene aggiornato dopo ogni versione generata da semantic-release - Posso avviare build su diversi branch per simulare il deployment su canali differenti. In ogni configurazione di XCode Cloud su un branch diverso, imposto manualmente una variabile d'ambiente con il valore di
branch.channelimpostato inreleaserc.json(sì, si tratta di una duplicazione manuale) e così facendo, se volessi, potrei distribuire un'applicazione AppStore diversa per ogni applicazione cliente personalizzata rilasciata da un branch di release dedicato, come menzionato in precedenza.
Build dei binari dell'app su XCode Cloud con canali Capgo
7. Conclusione
In conclusione, sono molto felice di aver integrato Capgo CapacitorUpdater nella mia pipeline standard di semantic release, in tempi rapidissimi durante 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 server Capgo
- semantic release distribuisce automaticamente i bundle dell'applicazione Capgo, utilizzando anche i canali Capgo
- questo si integra perfettamente con le build di XCode Cloud dei binari dell'applicazione
Prossimi passi
Attualmente sono nella fase di sviluppo di questa app. La renderò presto disponibile ai tester tramite TestFlight (per iOS). Data la potenza di Capgo, distribuirò sicuramente una versione gratuita dell'app sull'AppStore per i test, che verrà aggiornata regolarmente con Capgo durante le prove. Successivamente distribuirò un'altra versione (a pagamento) dell'app sull'AppStore, sotto un altro record, aggiornandola anch'essa regolarmente con Capgo.
Spero di aggiungere una migliore verifica pre-build per Capgo bundle upload dei prerequisiti nella mia configurazione di semantic release.
Ora ho una pipeline di semantic release pulita, semplice e riproducibile per i futuri app mobile sviluppate con Ionic + Angular + Capacitor.
Autore - Rupert Barrow
Ho oltre 22 anni di esperienza con Salesforce come cliente, utente, partner, integratore, architetto, sviluppatore, business analyst e consulente. Ho co-fondato e gestito Altius Services come COO e CTO per 13 anni, un partner SI di Salesforce di successo in Francia, prima di iniziare una nuova avventura come solopreneur Salesforce con la mia Cloud Rapido offerta di prodotti.
Puoi trovarmi su LinkedIn a https://linkedin.com/in/rbarrow.
Puoi dare un'occhiata alle nostre offerte Salesforce su https://www.rapido-companion.app e https://www.rapido.cloud (in fase di sviluppo).
Torna a: Come gestisco Semantic Release con Capgo CapacitorUpdater
Se stai usando Come Rapido Cloud gestisce Semantic Release con Capgo CapacitorUpdater per pianificare la distribuzione di live update, collegalo a Live Updates di Capgo per il workflow del prodotto in Capgo Live Updates, Panoramica per i dettagli di implementazione in Overview, Funzionalità per i dettagli di implementazione in Features, Comportamento degli update per i dettagli di implementazione in Update Behavior, e Tipi di update per i dettagli sull'implementazione in Update Types.
