1. Introduction
Au sein de Rapido Cloud (www.rapido.cloud), je développe une application mobile pour les clients Salesforce qui peuvent facilement déployer leur propre application mobile personnalisée sans passer par les difficultés des boucles de Salesforce Mobile SDK ou de l'éditeur de publication Salesforce Mobile.
J'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 un choix très réussi sans aucune surprise pour gérer tous les déploiements automatiquement via Github Actions. Toute cette chose a été conçue, testée et documentée pendant la période de 14 jours de 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.
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.
J'étais plutôt effrayé par la courbe d'apprentissage pour faire cela réussir mais j'ai pu mettre mon application sur Apple TestFlight avec facilité. J'ai ensuite pu utiliser Capacitor CapacitorUpdater pour déployer mes mises à jour beaucoup plus rapidement.
So Capgo CapacitorUpdater m'a aidé à mettre à jour mon application sur mon appareil mobile, en direct, 1 minute après avoir enregistré une nouvelle fonctionnalité ou une correction dans mon code source code : tellement soulageant, et si flexible, et facile à configurer !
3. Mon modèle de branchement et de mise en production, et comment semantic-release s'y insère
Maintenant que j'ai ma livraison vers les Capgo serveurs fonctionnant correctement, j'ai besoin d'automatiser cela et de l'intégrer dans ma chaîne d'intégration/chaîne de livraison.
C'est ainsi que j'organise mon modèle de branchement et de mise en production
Pour chaque application, qu'il s'agisse de mobile, web ou Salesforce :
- la mise au point a lieu sur
feature/...se débranche enmain, 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 des fonctionnalités spécifiques pour les livraisons personnalisées (en savoir plus ci-dessous) - les déploiements sont déclenchés à partir des branches de mise en production ce qui peut être :
production, branches de préversion (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 étant fusionnés dans une branche de déploiement. Je n'utilise pas les déploiements déclenchés par des tags car semantic release gère les tags et 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 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 le préversion alpha, beta, etc. dans le numéro de version.
La mise en production semantique génère le changelog à partir de vos commits, regroupant les correctifs et les fonctionnalités comme définis dans les commits conventionnels (voir https://www.conventionalcommits.org/en/about) et configurés dans la mise en production semantique.
Elle mettra également à jour toutes vos demandes de tirage de code (Github, dans mon cas) et les problèmes liés avec des commentaires les liant à la balise et à la mise en production. Enfin, dans cette Github mise en production, elle attache les éléments tels que les sources code, les binaires si nécessaire, etc. CHANGELOG.md4. Branches, mises en production/pré-mises en production, canaux dans la mise en production semantique et dans __CAPGO_KEEP_0__
Alors, pour les déploiements Capgo de la mise en production semantique, 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), and their own capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionet aussi capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionrepos. 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 fichiers de bundles JavaScript suivent la « standard » semver « Semantic Versioning » (https://semver.org semantic-release ) qui
suivent également (évidemment !) semantic-release C'est super, et c'est un soulagement pour moi car je les utilise
de manière intensive. Je veux aussi que semantic release génère les déploiements d'applications sur différents canaux
As 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 semantic release prend également en charge, donc je suis impatient de les faire fonctionner ensemble. Ces derniers s'insèrent également dans les différentes builds de branches gérées par XCode Cloud (voir plus sur cela ci-dessous).
Les numéros de version Semver générés par semantic release sur les préversions ressemblent à 1.0.0-alpha.1. Les builds successives 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 : je vais utiliser les canaux de semantic release et les préversions pour générer des versions de mon application avec Capgo canaux.
5. Comment puis-je utiliser Capgo pour lancer ma application ?
Pour automatiser le déploiement de vos fichiers de l'application 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 canal Capgo auquel nous voulons déployer (par exemple
alpha) - VERSION est généré par semantic release (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 semantic release + Capgo CapacitorUpdate configuration
Enfin, comment cela s'insère-t-il tous ensemble ?
Les versions de l'ensemble de l'application construites avec semantic release et Github Actions
Automatisation de la mise à jour avec semantic release et Github Actions
La beauté de semantic release est que l'automatisation de la mise à jour, sous forme d'un workflow 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 semantic release.
Pour chaque marge sur une branche listée dans branches, semantic release déclenchera une mise à jour.
Définissez CAPGO_APIKEY vos secrets de dépôt.
Mettez à jour votre CAPGO_APPID ici.
Le comportement de la mise en production semantique est défini dans son .releaserc.json fichier de configuration.
Voici mes paramètres, expliqués ci-dessous :
// .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:branchesconfigure les branches (name), mappées au canal Capgo (channel) et comment le numéro de version préalable sera appelé (prerelease). Par exemple, sibranch.prerelease = "development", le numéro de version généré par la mise en production semantique serax.y.z-development.n- les déploiements vers le
alphaet lesalpha-nocapgobranches déployeront tous deux l'application sur lealphamais avec des noms de version de préversion différents - les déploiements vers les branches développeurs
dev-rupertoudev-paulse déploieront tous les deux vers ledevelopmentcanal sur Capgo, tous avec le mêmedevelopmentmot-clé de préversion dans la version du numéro
verifyConditions: lors de la première étape de la mise en œuvre de la release semantique, il vérifie qu'il a accès correctement à Github. J'espère ajouter une vérification d'authentification pour le Capgo CLI ici plus tard@semantic-release/commit-analyzer: des choses standard de la mise en œuvre de la release semantique - 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 la mise en œuvre de la release semantique (package.json,CHANGELOG.mdetios/App/App.xcodeproj/project.pbxproj- Je ne construis pas pour Android, pourtant)@semantic-release/github: attachez leCHANGELOG.mdfichier à la Github version en tant qu'asset@semantic-release/exec: utilisez ces 2 commandes pour préparer la construction de l'application (prepareCmd) et puis pour construire et déployer effectivement l'application bundle sur les serveurs Capgo (publishCmd)
Vous remarquerez qu'il n'y a pas de manipulation 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 une version, etc. : tout est géré par défaut par semantic release, avec une configuration minimale.
Construction de nouveaux binaires avec XCode Cloud
Intégration de 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 il y a 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 constructions sur différentes branches pour simuler le déploiement pour différents canaux. Dans chaque configuration de construction XCode Cloud sur une branche différente, j'ai défini manuellement une variable d'environnement avec la valeur de
branch.channelconfiguré dansreleaserc.json(oui, c'est une duplication manuelle) et puis, si je le voulais, je pourrais déployer une autre application AppStore pour chaque application cliente personnalisée déployée à partir d'une branche de lancement personnalisée, comme mentionné précédemment.
Construction de fichiers d'application sur XCode Cloud avec des canaux Capgo
7. Conclusion
En conclusion, je suis très heureux d'avoir pu intégrer Capgo CapacitorUpdater dans mon pipeline de lancement sémantique 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 des bundles sont générés automatiquement par la lancement sémantique et sont compatibles avec les serveurs Capgo
- la lancement sémantique déploye automatiquement les bundles d'application Capgo, en utilisant également les canaux Capgo
- cela s'intègre bien avec les constructions de fichiers d'application XCode Cloud
Étapes suivantes
Je suis actuellement en phase de développement de cette application. Je vais la rendre rapidement 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.
J'espère ajouter une vérification pré-construction améliorée de Capgo bundle upload prérequis dans ma configuration de release semantique.
J'ai maintenant une pipeline de release 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 de 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 de Salesforce réussi en France, avant de partir à une nouvelle aventure en tant que solopreneur Salesforce avec mon Rapido Cloud offre de produit.
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 https://www.rapido.cloud (en cours de développement).
Continuez à partir de Comment Rapido Cloud gère la mise à jour semestrielle avec Capgo CapacitorUpdater
Si vous utilisez Comment Rapido Cloud gère la mise à jour semestrielle avec Capgo CapacitorUpdater pour planifier la livraison d'actualisations en direct, connectez-le à Capgo Mises à jour en direct for the product workflow in Capgo Live Updates, pour les détails d'implémentation dans Vue d'ensemble Caractéristiques pour les détails d'implémentation dans Caractéristiques Comportement de mise à jour Comportement de mise à jour pour les détails d'implémentation dans Mise à jour du comportement, et Types de mise à jour pour les détails d'implémentation dans Types de mise à jour.
