Comment Rapido Cloud gère la mise en production semantique avec Capgo CapacitorUpdater

1. Introduction

Au sein de 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 mobile personnalisée sans avoir à passer par les difficultés de l'utilisation de la plateforme Salesforce Mobile SDK ou de l'éditeur 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, telles que les composants Lightning Web ; et cela 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 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.

C'est ma première application mobile que je publie dans les magasins, ayant concentré mon attention dans le passé sur les applications web, généralement développées sur l'expérience Cloud Salesforce. J'étais plutôt inquiet de l'apprentissage de la courbe pour faire cela 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 !

Le Capgo CapacitorUpdater m'a aidé à mettre à jour mon application sur mon 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 mon déploiement vers les Capgo serveurs fonctionnant correctement, j'ai besoin d'automatiser cela et de l'intégrer dans mon pipeline CI/CD.

C'est ainsi que j'organise mon modèle de branchement et de mise en production

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

• la mise en œuvre a lieu sur feature/... se débranche en main, et elles sont fusionnées dans main qui 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 de branches de version qui peuvent être : production, des branches de version préalables (alpha, beta, nightly, etc.) et aussi des branches spécifiques pour les 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 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 de la dernière tag 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 les versions préalables alpha, betaetc. dans la version numéro.

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

Ce processus mettra également à jour tous vos pull requests et les problèmes liés (Github, dans mon cas) avec des commentaires les liant à la tag et à la release. Enfin, dans cette Github release, il attacher les assets comme les sources code, les binaires si nécessaire, CHANGELOG.mdetc.

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

Alors, pour les déploiements de Capgo, je veux que semantic release fasse les choses suivantes.

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

Capgo ont développé et documenté leur propre version de la « Conventional Commits » standard-version outil, avec leur fork de repo standard-version (https://github.com/Cap-go/standard-versionet 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 fichiers de bundles JavaScript suivent la « standard » semver « Semantic Versioning » (https://semver.org) qui semantic-release suivent également (évidemment !)

Cela signifie que c'est génial, et c'est un soulagement pour moi car je les utilise semantic-release de manière intensive.

I also want semantic release to generate app deployments on different canaux

As mentioned above, I need to deploy la 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 ravi de les faire travailler ensemble. Ces dernières s'insèrent également dans les différentes constructions de branchement gérées par XCode Cloud (voir plus en bas).

Les numéros de version Semver générés par semantic release sur les préversions ressemblent à 1.0.0-alpha.1. Les constructions successives sur cette branche augmenteront le numéro de construction à 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 et les préversions de semantic release 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. Type 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 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 setup de mise à jour de Capacitor avec semantic release et Capgo

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

Les versions des bundles d'applications construites avec semantic release et Github Actions

Automatisation de la mise en production avec semantic release et Github Actions

La beauté de semantic release est que l'automatisation de la mise en production, sous forme d'un 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 semantic release.

Pour chaque mérge sur une branche listée dans branchesLa mise à jour semantique déclenchera une mise en production. CAPGO_APIKEY Configurez CAPGO_APPID dans les secrets de votre dépôt.

Mise à jour de .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 :
  • branches Le comportement de la mise à jour semantique est défini dans sonname), mapped to the Capgo channel (channelIci sont mes paramètres, expliqués ci-dessous :prereleaseconfigure les branches ( branch.prerelease = "development"), mappées au canal ( x.y.z-development.n
  • ) et comment le numéro de version préalable sera appelé ( alpha). Par exemple, si vous choisissez (", le numéro de version généré par la mise à jour semantique sera (". Les mises à jour sont envoyées vers le (" et le (". alpha-nocapgo les branches déployeront toutes deux l'application sur le alphacanal, mais avec des noms de version de préversion différents
  • les déploiements aux branches du développeur dev-rupertou dev-paul se déployeront toutes deux sur le developmentcanal sur Capgo, toutes avec le même developmentmot-clé de version de préversion dans le numéro de version
• verifyConditions : lors de la première étape de la mise en œuvre de la sérialisation, il vérifie qu'il a accès au Github correct. 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 sérialisation - 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 comme CHANGELOG.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 sérialisation (package.json, CHANGELOG.md et ios/App/App.xcodeproj/project.pbxproj - Je ne construis pas pour Android, pourtant)
• @semantic-release/github : attachez le CHANGELOG.md fichier au Github release 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 fastidieuse pour expliquer comment nous voulons que le numéro de version soit calculé et incrémenté, comment nous devons générer un fichier de changelog, un Github tag ou release, 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.md fichier 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.channel définie dans releaserc.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 client personnalisée déployée à partir d'une branche de lancement personnalisée, comme mentionné plus tôt.

Construction de 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 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 mettre à jour régulièrement celle-ci avec Capgo.

J'espère ajouter une vérification pré-build plus efficace de Capgo bundle upload pour les prérequis dans ma configuration de publication sémantique.

J'ai maintenant un pipeline de publication sémantique 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 Salesforce réussi en France, avant de lancer 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 à nos offres Salesforce sur.

https://www.rapido-companion.app et et https://www.rapido.cloud En cours de développement.