Comment Rapido Cloud gère la mise en production semantique avec Capgo CapacitorUpdater
1. IntroductionÀ 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 ai développé cette application mobile sur une plateforme moderne et "standard" avec des composants et des outils largement répandus, notamment Ionic 8, Angular 18, TypeScript, Capacitor et maintenant Capgo CapacitorUpdater. Ces derniers sont plus simples à gérer pour les clients qui ne veulent pas gérer les spécificités de la plateforme Salesforce, comme les composants Lightning Web ; et c'est plus facile et moins coûteux pour moi de recruter des développeurs et des mainteneurs d'applications mobiles Ionic + Angular.
Cet article explique mon design, mes choix et ma mise en œuvre qui font de Capgo et semantic-release une solution très réussie et sans équivoque pour gérer tous les déploiements automatiquement via Github Actions. Toute cette mise en œuvre a été conçue, testée et documentée pendant la période de 14 jours d'essai gratuit de Capgo CapacitorUpdater.
2. Pourquoi utiliser Capgo ? Pourquoi utiliser semantic-release ?
Capgo CapacitorUpdater m'a attiré par sa promesse de rendre les déploiements d'applications mobiles beaucoup plus simples, beaucoup plus rapides et flexibles que le processus standard de livraison Apple AppStore/Google PlayStore.
J'étais plutôt inquiet de la courbe d'apprentissage pour réussir, mais j'ai pu mettre mon application sur Apple TestFlight avec facilité. J'ai ensuite pu utiliser Capgo CapacitorUpdater pour déployer mes mises à jour beaucoup plus rapidement.
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. Mon modèle de branchement et de publication, et comment semantic-release s'y insère
So now I have my delivery to Capgo servers working correctly, I need to automate this and fit it into my CI/CD pipeline.
C'est ainsi que j'organise mon modèle de branchement et de publication
Pour chaque application, qu'il s'agisse de mobile, web ou Salesforce :
- le développement se déroule sur
feature/...des branches qui se détachentmain, et elles sont fusionnées dansmainqui est la référence pour la plupart des branches de développement, à l'exception de la maintenance et de fonctionnalités spécifiques pour les livraisons personnalisées (en savoir plus ci-dessous) - les déploiements sont déclenchés à partir de branches de version qui peuvent être :
production, des branches de version préalables (alpha,beta,nightly, etc.) et aussi des branches spécifiques au client ou au contexte pour des livraisons personnalisées - les déploiements sont déclenchés par une demande de tirage qui est fusionnée dans une branche de déploiement. Je ne utilise pas les déploiements déclenchés par des tags car semantic release gère les tags et tout le reste pour moi.
En résumé, c'est le flux Gitlab :
Flux Gitlab - source https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Remarque secondaire sur la façon dont semantic-release fonctionne :
Dans une branche de déploiement, lorsque semantic-release est déclenché, il calculera automatiquement le nouveau numéro de version sur cette branche, en fonction du numéro de version du tag précédent sur la branche et des correctifs ou des fonctionnalités livrés. Les correctifs créeront une nouvelle version de patch, tandis que les fonctionnalités créeront une nouvelle version mineure. Il inclut également automatiquement les préversions alpha, betaetc. dans le numéro de version.
La mise en œuvre de la sémiotique génère le changelog à partir de vos commits, groupant les correctifs et les fonctionnalités comme définis dans les commits conventionnels (voir https://www.conventionalcommits.org/fr/about) et configurés dans la mise en œuvre de la sémiotique.
Elle mettra également à jour tous vos pull requests de fusion de git (Github, dans mon cas) et les problèmes liés avec des commentaires les liant à l'étiquette et à la mise en œuvre. Enfin, dans cette Github mise en œuvre, elle attache des éléments tels que des sources code, des binaires si nécessaire, etc. CHANGELOG.md4. Branches, mises en œuvre/lancements/prélancements, canaux dans la mise en œuvre de la sémiotique et dans __CAPGO_KEEP_0__
Alors, pour les déploiements Capgo de la mise en œuvre de la sémiotique, je veux que cela fasse les choses suivantes.
So what I want semantic release to do for Capgo deployments is the following.
__CAPGO_KEEP_0__ ont développé et documenté leur propre version de la ‘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-version), et leurs propres capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) ainsi que capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. Ils ont documenté sur leur blog le schéma de version utilisé par Capgo dans leurs déploiements (https://capgo.app/blog/comment-fonctionne-la-versionnage-dans-capgo/). Les bundles JavaScript suivent la « standard » semver « Semantic Versioning » (https://semver.org) qui semantic-release également suit (évidemment !)
Par conséquent, c'est super, et c'est un soulagement pour moi car je les utilise semantic-release de manière intensive.
I souhaite également que la mise en œuvre de la version sémantique génère des déploiements d'applications sur différents canaux
Comme mentionné ci-dessus, j'ai besoin de déployer une version de préversion à partir de branches telles que alpha, beta, nightly etc., mais aussi des versions spécifiques aux clients sur des branches telles que production-customer-jones, production-customer-doe, etc.
Capgo fournit la fonctionnalité des « canaux » qui est exactement ce que la mise en œuvre de la version sémantique prend également en charge, donc je suis impatient de les faire travailler ensemble. Ces éléments s'inscrivent également dans les différents builds de branchement gérés par XCode Cloud (voir plus de détails ci-dessous).
Les numéros de version Semver générés par la mise en œuvre de la version sémantique sur les préversions ressemblent à 1.0.0-alpha.1Les builds successifs sur cette branche incrémenteront le numéro de build à 1.0.0-alpha.2, etc. Bien que ces numéros de version ne soient pas documentés explicitement, ils sont pris en charge par Capgo, ce qui est une excellente nouvelle pour moi : j'utiliserai les canaux et les préversions de la mise en œuvre de la version sémantique pour générer des versions de mon application avec les canaux Capgo.
5. Comment puis-je utiliser Capgo pour lancer ma application ?
Pour automatiser le déploiement de vos fichiers de bundle d'applications vers Capgo, vous devez utiliser la commande Capgo CLI bundle upload. Tapez npx @capgo/cli@latest bundle upload --help pour obtenir les nombreuses options d'upload. Parmi celles-ci, nous utiliserons les suivantes :
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL est le Capgo canal vers lequel nous voulons déployer (par exemple
alpha) - VERSION est générée par la mise en œuvre de la sémiotique (par exemple
1.0.0-alpha.1) - CAPGO_APIKEY est fourni par Capgo pour identifier de manière unique votre pipeline de CI/CD de connexion
- CAPGO_APPID est fourni par Capgo pour identifier de manière unique votre application (par exemple
com.mystartup.mysuperapp)
6. Mon setup de mise en œuvre de la sémiotique + Capgo CapacitorUpdate
Enfin, comment cela s'insère-t-il tous ensemble ?
Les versions de l'application en bundle construites avec la mise en œuvre de la sémiotique et Github Actions
Automatisation de la mise en œuvre de la sémiotique avec Github Actions
La beauté de la mise en œuvre de la sémiotique est que l'automatisation de la mise en œuvre, sous forme de flux de travail Github Actions, est très simple. Cela ressemblera beaucoup aux autres plateformes de 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 }}Cela installe simplement l'environnement NodeJS, puis appelle la mise en œuvre de la sémiotique.
Pour chaque mérge sur une branche listée dans branchesLa mise en œuvre de la mise en forme sémantique déclenchera une mise en production. CAPGO_APIKEY Configurez CAPGO_APPID en secret de votre dépôt.
Mettez à jour votre .releaserc.json ici.
// .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:branchesLe comportement de la mise en forme sémantique est configuré dans sonname), mapped to the Capgo channel (channelexpliqué ci-dessous :prereleaseconfigure les branches (branch.prerelease = "development"et le canal (x.y.z-development.n- ) et comment le numéro de version préalable sera appelé (
alpha). Par exemple, si vous souhaitez que le numéro de version généré par la mise en forme sémantique soit « alpha », le numéro de version généré sera « alpha.x.x ».alpha-nocapgoles branches déployeront l'application sur lealphale canal, mais avec des noms de version de préversion différents - les déploiements sur les branches de développement
dev-rupertoudev-paulle canal, mais avec le même mot de préversion dans le numéro de versiondevelopmentchannel on Capgo, all with the samedevelopmentJ'espère ajouter une vérification d'authentification pour le
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: les choses standard de la mise en œuvre sémantique - voir leur documentation (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: générer le fichier de changelog commeCHANGELOG.md@semantic-release/git: commiter les fichiers suivants qui ont été mis à jour par la construction Ionic de l'application et par le travail de mise en œuvre sémantique (package.json,CHANGELOG.mdetios/App/App.xcodeproj/project.pbxproj- Je ne construis pas pour Android, pourtant)@semantic-release/github: attachez leCHANGELOG.mdfichier au lancement Github comme un élément@semantic-release/exec: utilisez ces 2 commandes pour préparer la construction de l'application (prepareCmd) et puis pour construire et déployer efficacement l'application bundle sur les serveurs Capgo (publishCmd)
Vous remarquerez qu'il n'y a pas de manipulation fastidieuse pour expliquer comment nous voulons que le numéro de version soit calculé et incrémenté, comment nous devons générer un changelog, un Github tag ou lancement, etc. : tout est géré par défaut par semantic release, avec une configuration minimale.
Construction de nouvelles binaires avec XCode Cloud
Intégrer tout cela avec XCode Cloud pour construire de nouvelles versions du fichier binaire de l'application est simple (Je ne déploie pas encore sur Google Play, mais cette construction devrait être similaire) :
- J'ai configuré un processus XCode Cloud pour construire lorsque se produit une modification sur la branche que je souhaite utiliser pour cela (par exemple
production) - sur cette branche, j'ai configuré XCode Cloud pour construire uniquement lorsque le
CHANGELOG.mdfichier est mis à jour. Cela est mis à jour après chaque version générée par semantic release - Je peux déclencher des builds sur différentes branches pour simuler la mise en production pour différents canaux. Dans chaque configuration de build XCode Cloud sur une branche différente, j'ajoute manuellement une variable d'environnement avec la valeur de
branch.channelconfiguré enreleaserc.json(oui, c'est une duplication manuelle) et puis, si je le voulais, je pouvais déployer une application AppStore différente pour chaque application cliente personnalisée déployée à partir d'une branche de version personnalisée, comme mentionné plus tôt.
Construction de fichiers binaires d'applications sur XCode Cloud avec Capgo canaux
7. Conclusion
En conclusion, je suis très heureux d'avoir pu intégrer Capgo CapacitorUpdater dans ma pipeline de release semantique standard, rapidement dans le délai de la période d'essai de 14 jours, et le résultat est le suivant :
- Les numéros de version de bundle sont générés automatiquement par la release semantique et sont compatibles avec les Capgo serveurs
- La release semantique déploye automatiquement les Capgo bundles d'applications, en utilisant également les Capgo canaux
- Cela s'intègre bien avec les builds XCode Cloud de fichiers binaires d'applications
Étapes suivantes
Je suis actuellement en phase de développement de cette application. Je vais rapidement la rendre disponible aux testeurs via TestFlight (pour iOS). Étant donné la puissance de Capgo, je vais certainement déployer une version gratuite de l'application sur l'AppStore pour les tests, qui sera mise à jour régulièrement avec Capgo pendant les tests. Je vais ensuite déployer une autre (payante) version de l'application sur l'AppStore, sous un autre enregistrement, et la mettre à jour régulièrement avec Capgo.
I espère ajouter une meilleure vérification préalable de Capgo bundle upload les prérequis dans ma configuration de libération semantique.
J'ai maintenant un pipeline de libération semantique propre, simple et réplicable pour les futures applications mobiles développées avec Ionic + Angular + Capacitor.
Auteur - Rupert Barrow
J'ai plus de 22 ans d'expérience en Salesforce, en tant que client et utilisateur, en tant que partenaire et intégrateur, architecte, développeur, analyste commercial et consultant. J'ai co-fondé et co-géré Altius Services en tant que COO et CTO pendant 13 ans, un partenaire SI Salesforce réussi en France, avant de partir à une nouvelle aventure en tant que solopreneur Salesforce avec mon offre de produit Rapido Cloud. Vous pouvez me trouver sur LinkedIn à
https://linkedin.com/in/rbarrow Vous pouvez jeter un coup d'œil sur nos offres Salesforce à.
https://www.rapido-companion.app et contexte : Page/zone : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément court. Vu dans : page trust.astro. Clé de message `et` (Et). https://www.rapido.cloud (en développement).
Continuez de How Rapido Cloud gère la mise en production de Semantic Release avec Capgo CapacitorUpdater
Si vous utilisez How Rapido Cloud gère la mise en production de Semantic Release avec Capgo CapacitorUpdater pour planifier la livraison d'actualisations en direct, connectez-l’à Capgo Mises à jour en direct for the product workflow in Capgo Live Updates, pour le flux de travail du produit dans __CAPGO_KEEP_0__ Mises à jour en direct, Aperçu pour les détails d'implémentation dans Aperçu, Fonctionnalités Comportement de mise à jour pour le détail d'implémentation dans Comportement de mise à jour, et Types de mise à jour pour le détail d'implémentation dans Types de mise à jour.
