Comment Rapido Cloud gère Semantic Release avec Capgo CapacitorUpdater

1. Introduction

Chez Rapido Cloud (www.rapido.cloud), je développe une application mobile pour les clients Salesforce afin qu'ils puissent déployer facilement leur propre application de marque sans subir les cycles complexes du Salesforce Mobile SDK ou du Salesforce Mobile Publisher.

J'ai développé cette application mobile sur une plateforme moderne et « standard » avec des composants et outils largement répandus, notamment Ionic 8, Angular 18, TypeScript, Capacitor et maintenant Capgo CapacitorUpdater. Ces outils sont plus simples à gérer pour les clients qui ne souhaitent pas gérer les spécificités de la plateforme Salesforce comme les Lightning Web Components ; et il 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 ma conception, mes choix et mon implémentation qui font de Capgo et semantic-release une solution évidente et très efficace pour gérer tous les déploiements automatiquement via Github Actions. Tout cela a été conçu, testé et documenté durant la période d'essai gratuite de 14 jours de Capgo CapacitorUpdater.

2. Pourquoi utiliser Capgo ? Pourquoi utiliser semantic-release ?

Capgo CapacitorUpdater m'a séduit par sa promesse de rendre le déploiement d'applications mobiles bien plus simple, rapide et flexible que le processus de livraison standard de l'App Store d'Apple ou du Play Store de Google. C'est ma première application mobile que je publie sur les stores, après m'être concentré par le passé sur les applications web, généralement développées sur Salesforce Experience Cloud.

J'appréhendais un peu la courbe d'apprentissage pour réussir ce projet, mais j'ai pu mettre mon application sur Apple TestFlight assez facilement. J'étais alors en mesure d'utiliser Capgo CapacitorUpdater pour déployer mes mises à jour beaucoup plus rapidement.

Mon premier besoin et cas de test était de déployer l'application pour moi-même afin de la tester comme une véritable application mobile sur mon propre téléphone, plutôt que de tester via un émulateur ou un simulateur sur le navigateur mobile Nexus suggéré par Ionic. En effet, mon application utilise des fonctionnalités natives comme la géolocalisation ou l'accès à la galerie photo et à l'appareil photo. N'ayant jamais testé d'application mobile Capacitor auparavant, je n'étais pas certain que tout fonctionnerait correctement : rien de tel que de tester la vraie application, en conditions réelles !

Ainsi, Capgo CapacitorUpdater m'a aidé à mettre à jour mon application sur mon mobile, en direct, une minute seulement après avoir sauvegardé une nouvelle fonctionnalité ou un correctif dans mon code source : quel soulagement, et quelle flexibilité, le tout si facile à configurer !

3. Mon modèle de branching et de release, et comment semantic-release s'y intègre

Maintenant que mon envoi vers les serveurs de Capgo fonctionne correctement, je dois automatiser tout cela et l'intégrer dans mon pipeline CI/CD.

Voici comment j'organise mon modèle de branching et de release

Pour chaque application, qu'elle soit mobile, web ou Salesforce :

• le développement s'effectue sur des feature/... branches dérivées main, qui sont ensuite fusionnées dans main qui sert de référence pour la plupart des branches de développement, en dehors de la maintenance et des fonctionnalités spécifiques pour des livraisons personnalisées (plus de détails ci-dessous)
• les déploiements sont déclenchés depuis des branches de release qui peuvent être : production, des branches de prerelease (alpha, beta, nightly, etc.) ainsi que des branches spécifiques au client ou au contexte pour des livraisons personnalisées
• les déploiements sont déclenchés par une pull request fusionné dans une branche de déploiement. Je n'utilise pas de déploiements déclenchés par des tags, car semantic-release gère les tags et tout le reste pour moi.

En gros, c'est le Gitlab Flow :

Gitlab Flow - source https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

Note sur le fonctionnement de semantic-release :

Dans une branche de déploiement, quand semantic-release est déclenché, il calculera automatiquement le nouveau numéro de version sur cette branche, selon le numéro de version du tag précédent et les correctifs ou fonctionnalités livrés. Les correctifs créeront une nouvelle version patch, tandis que les fonctionnalités créeront une nouvelle version minor. Il inclut également automatiquement la prerelease alpha, beta, etc. dans le numéro de version.

Semantic release génère le changelog à partir de vos commits, en regroupant les correctifs et les fonctionnalités selon les conventions de commits (voir https://www.conventionalcommits.org/en/about) et configuré dans semantic release.

Il mettra également à jour toutes vos pull requests fusionnées sur git (Github, dans mon cas) ainsi que les issues associées avec des commentaires les liant au tag et à la release. Enfin, dans cette release Github, il joindra des assets tels que le code source, les binaires si nécessaire, CHANGELOG.md, etc.

4. Branches, releases/prereleases, canaux dans semantic release et dans Capgo

Voici donc ce que je veux que semantic release fasse pour les déploiements Capgo.

Je veux que semantic release génère le numéro de version

Capgo ont développé et documenté leur propre version des « Conventional Commits » standard-version outil, avec leur repo forké 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-fonctionnent-les-versions-dans-capgo/). Les bundles JavaScript suivent le semver « standard » (Semantic Versioning) (https://semver.org) qui semantic-release suit également (évidemment !)

C'est une excellente nouvelle, et un vrai soulagement pour moi car j'utilise semantic-release intensivement.

Je souhaite également que semantic-release génère des déploiements d'app sur différents canaux

Comme indiqué plus haut, je dois déployer une version prerelease depuis des 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 propose la fonctionnalité de « canaux », ce qui correspond exactement à ce que supporte semantic release ; je suis donc ravi de les faire fonctionner ensemble. Cela s'intègre également aux différents builds de branches gérés par Xcode Cloud (voir plus de détails ci-dessous).

Les numéros de version Semver générés par semantic release sur les prereleases ressemblent à ceci : 1.0.0-alpha.1. Les builds successifs sur cette branche incrémenteront le numéro de build à 1.0.0-alpha.2, etc. Bien qu'ils ne soient pas explicitement documentés, ces numéros de version sont supportés par Capgo, ce qui est une excellente nouvelle pour moi : je vais utiliser les canaux semantic release et les prereleases pour générer des versions de mon app avec les canaux Capgo.

5. Comment utiliser Capgo pour publier mon application ?

Pour automatiser le déploiement de vos bundles d'application vers Capgo, vous devez utiliser la commande Capgo CLI de Capgo bundle upload. Tapez npx @capgo/cli@latest bundle upload --help pour accéder aux 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 vers lequel nous voulons déployer (ex : alpha)
• VERSION est générée par semantic release (ex : 1.0.0-alpha.1)
• CAPGO_APIKEY est fournie par Capgo pour identifier de manière unique l'identifiant de votre pipeline CI/CD
• CAPGO_APPID est fournie par Capgo pour identifier de manière unique votre application (ex : com.mystartup.mysuperapp)

6. Ma configuration semantic-release + Capgo CapacitorUpdate

Enfin, comment tout cela s'articule-t-il ?

Versions du bundle de l'app compilées avec semantic release et Github Actions

Automatisation de semantic-release avec Github Actions

L'avantage de semantic release, c'est que l'automatisation du déploiement, sous la forme d'un workflow Github Action, est très simple. Ce sera très similaire sur d'autres plateformes 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 merge sur une branche listée dans branches, semantic release déclenchera un déploiement. Définissez CAPGO_APIKEY dans les secrets de votre dépôt. Mettez à jour votre CAPGO_APPID ici.

Le comportement de semantic release 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 :
  • branches définit la configuration des branches (name), mappées au canal Capgo (channel) et la manière dont le numéro de version prerelease sera nommé (prerelease). Par exemple, si branch.prerelease = "development", le numéro de version généré par semantic release sera x.y.z-development.n
  • déploiements vers les alphaet alpha-nocapgo branches déploieront toutes deux l'app sur le alphacanal, mais avec des noms de prerelease différents dans le numéro de version
  • déploiements vers les branches de développement dev-rupertou dev-paul déploieront tous les deux sur le developmentcanal de Capgo, le tout avec le même developmentmot-clé prerelease dans le numéro de version
• verifyConditions : lors de la première étape de semantic release, il vérifie qu'il a bien accès à Github. Je prévois d'ajouter une vérification d'authentification pour le Capgo CLI ici plus tard
• @semantic-release/commit-analyzer : le fonctionnement standard de semantic release - 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 changelog en tant que CHANGELOG.md
• @semantic-release/git : commiter les fichiers suivants, mis à jour par le build Ionic de l'application et par le travail de semantic release (package.json, CHANGELOG.md et ios/App/App.xcodeproj/project.pbxproj - je ne compile pas encore pour Android)
• @semantic-release/github : joindre le CHANGELOG.md fichier à la release Github en tant qu'asset
• @semantic-release/exec: utilisez ces 2 commandes pour préparer le build de l'app (prepareCmd) puis pour déployer concrètement le bundle de l'app sur les serveurs Capgo (publishCmd)

Vous remarquerez qu'il n'y a aucune manipulation complexe pour expliquer comment le numéro de version doit être calculé et incrémenté, comment générer un changelog, un tag ou une release Github, etc. : tout est géré par défaut par semantic release, avec une configuration minimale.

Générer de nouveaux binaires avec XCode Cloud

Intégrer tout cela avec XCode Cloud pour générer de nouvelles versions du binaire de l'application est simple (je ne déploie pas encore sur Google Play, mais ce build devrait être similaire) :

• J'ai configuré un processus XCode Cloud pour lancer un build lorsqu'un changement survient sur la branche que je souhaite utiliser (ex : production)
• sur cette branche, je configure XCode Cloud pour ne lancer un build que lorsque le CHANGELOG.md fichier est mis à jour. Celui-ci 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 le déploiement pour différents canaux. Dans chaque configuration de build Xcode Cloud sur une branche différente, je définis manuellement une variable d'environnement avec la valeur de branch.channel définie dans releaserc.json (oui, c'est une duplication manuelle) et ensuite, si je le voulais, je pourrais déployer une application App Store différente pour chaque application client personnalisée déployée depuis une branche de release personnalisée, comme mentionné plus haut.

Compiler les binaires de l'app sur Xcode Cloud avec les canaux Capgo

7. Conclusion

En conclusion, je suis ravi d'avoir pu intégrer Capgo CapacitorUpdater dans mon pipeline de semantic release standard, et ce rapidement, dans le délai de la période d'essai de 14 jours. Le résultat est le suivant :

• les numéros de version des bundles sont générés automatiquement par semantic-release et sont compatibles avec les serveurs Capgo
• semantic release déploie automatiquement les bundles d'application Capgo, en utilisant aussi les canaux Capgo
• cela s'intègre parfaitement aux builds Xcode Cloud des binaires de l'application

Prochaines étapes

Je suis actuellement en phase de développement de cette app. Je la rendrai rapidement disponible aux testeurs via TestFlight (pour iOS). Au vu de la puissance de Capgo, je déploierai très certainement une version gratuite de l'app sur l'App Store pour les tests, qui sera mise à jour régulièrement avec Capgo pendant les tests. Je déploierai ensuite une autre version (payante) de l'app sur l'App Store, sous une autre fiche, et je la mettrai aussi à jour régulièrement avec Capgo.

J'espère ajouter une meilleure vérification pré-build des prérequis de Capgo bundle upload dans ma configuration de semantic release.

J'ai désormais un pipeline de semantic release propre, simple et reproductible pour mes futures applications mobiles développées avec Ionic + Angular + Capacitor.

Auteur - Rupert Barrow

J'ai plus de 22 ans d'expérience sur Salesforce, en tant que client, utilisateur, partenaire, intégrateur, architecte, développeur, analyste métier et consultant. J'ai cofondé et co-dirigé Altius Services en tant que COO et CTO pendant 13 ans, un partenaire SI Salesforce reconnu en France, avant de me lancer dans une nouvelle aventure de solopreneur Salesforce avec mon offre de produits Rapido Cloud.

Vous pouvez me retrouver sur LinkedIn à l'adresse https://linkedin.com/in/rbarrow.

Vous pouvez consulter nos offres Salesforce sur https://www.rapido-companion.app et https://www.rapido.cloud (en cours de développement).

Continuer avec : Comment Rapido Cloud gère Semantic Release avec Capgo CapacitorUpdater

Si vous utilisez Comment Rapido Cloud gère Semantic Release avec Capgo CapacitorUpdater pour planifier la livraison de live update, connectez-l’à Capgo Live Updates pour le workflow produit dans Capgo Live Updates, Aperçu pour les détails d'implémentation dans Vue d'ensemble, Fonctionnalités pour le détail d’implémentation dans Fonctionnalités, Comportement de mise à jour pour les détails d'implémentation dans Update Behavior, et Types de mise à jour pour les détails d'implémentation dans Update Types.