Voici comment Rapido Cloud gère la mise à jour semestrielle avec Capgo CapacitorUpdater

1. Introduction

À 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 devoir passer par les difficultés des boucles de l'application 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, telles que 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. Tout cela a été conçu, testé et documenté pendant la période d'essai gratuite de 14 jours de Capgo CapacitorUpdater.

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

Capgo CapacitorUpdater m'a attiré par sa promesse de simplifier, d'accélérer et de rendre plus flexible le déploiement d'applications mobiles, beaucoup plus simple, beaucoup plus rapide et flexible que le processus standard de livraison par l'App Store Apple/Google Play Store.

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.

Mon premier objectif et cas de test était de déployer pour moi-même pour tester mon application comme une vraie application mobile sur mon propre téléphone, au lieu de tester dans un émulateur mobile ou dans un simulateur via le navigateur mobile Nexus suggéré par IIonic. C'est parce que mon application utilise des fonctionnalités natives telles que la géolocalisation ou l'accès à la galerie photo et à la caméra. Sans avoir l'expérience passée de tester une Capacitor application mobile, je n'étais pas sûr que tout allait fonctionner correctement : rien de mieux que de tester l'application réelle, dans des conditions réelles !

Ainsi 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 livraison, 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 ma chaîne d'intégration/chaîne de livraison.

Voici comment j'organise mon modèle de branchement et de mise en production

Pour chaque application, qu'il s'agisse de mobile, web ou Salesforce :

• le développement se déroule sur feature/... des branches dérivées main, et elles sont fusionnées dans main qui constitue la référence pour la plupart des branches de développement, à l'exception de la maintenance et de fonctionnalités spécifiques pour des livraisons personnalisées (en savoir plus ci-dessous)
• les déploiements sont déclenchés à partir des branches de mise en production qui peuvent être : production, des branches de préversion (alpha, beta, nightly, etc.) et également des branches spécifiques pour les clients ou le contexte pour des livraisons personnalisées
• Les déploiements sont déclenchés par une demande de tirage. Je ne utilise pas les déploiements déclenchés par tag 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é-lancement alpha, beta, etc. dans le numéro de version.

Semantic release 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/en/about) et configurés dans semantic release.

It will also update all your git (Github, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this Github release, it will attach assets such as source code, binaries if necessary, CHANGELOG.md4. Branches, releases/prereleases, canaux dans semantic release et dans __CAPGO_KEEP_0__

Alors, pour les déploiements de Capgo, je veux que semantic release 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-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-standard-version capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-plugin-standard-version capacitor-plugin-standard-version (It will also update all your git (github, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this capacitor release, it will attach assets such as source __CAPGO_KEEP_2__, binaries if necessary, etc. 4. Branches, releases/prereleases, channels in semantic release and in github So what I want semantic release to do for github deployments is the following. I want semantic release to generate the version number github have developed and documented their own version of the “Conventional Commits” tool, with their forked repo https://github.com/Cap-go/standard-version, ) and their own https://github.com/Cap-go/capacitor-standard-version, ) as well as https://github.com/Cap-go/capacitor-plugin-standard-versionLes dépôts. 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 le « standard » semver « Semantic Versioning » (https://semver.org) qui suit également (évidemment !) semantic-release C'est donc super, et c'est un soulagement pour moi car je l'utilise

Je veux également que semantic release génère les déploiements d'applications sur différents canaux semantic-release Comme mentionné ci-dessus, j'ai besoin de déployer des versions préalables à partir de branches telles que

mais également des versions spécifiques aux clients sur des branches telles que

, etc. alpha, beta, nightly I also want semantic release to generate app deployments on different channels production-customer-jones, production-customer-doeAs mentioned above, I need to deploy prerelease version from branches such as

Capgo fournit la fonctionnalité des « canaux » qui correspond exactement à ce que semantic release prend en charge également, donc je suis impatient de les faire fonctionner ensemble. Ces derniers s'intègrent également dans les différentes versions de branche 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 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. Type npx @capgo/cli@latest bundle upload --help pour obtenir les nombreuses options de téléchargement. 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 CI/CD de connexion
• CAPGO_APPID est fourni par Capgo pour identifier de manière unique votre application (par exemple com.mystartup.mysuperapp)

6. Ma mise en production semantique + Capgo CapacitorUpdate setup

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

Versions de l'ensemble d'application construites avec la mise en production semantique et Github Actions

Automatisation de la mise en production semantique avec Github Actions

La beauté de la mise en production semantique 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 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 production semantique.

Pour chaque mérge sur une branche listée dans branches, la mise en production semantique déclenchera une mise en production. Définir CAPGO_APIKEY dans les secrets de votre dépôt. Mettre à jour votre CAPGO_APPID ici.

Le comportement de la mise en production semantique est défini dans ses .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ée au canal Capgo (channel) et comment le numéro de version préalable sera appelé (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 le alphaet les alpha-nocapgo s'envoyeront tous deux le déploiement de l'application sur le canal alphamais avec des noms de version préalable différents dans le numéro de version
  • déploiements vers les branches de développement dev-rupertou dev-paul se déploieront tous deux sur le developmentcanal sur Capgo, tous avec le même developmentmot clé de préversion dans le numéro de version
• verifyConditions : lors de la première étape de la mise en œuvre de la libération sémantique, 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 : affaires standard de libération 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 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 libération sémantique (package.json, CHANGELOG.md et ios/App/App.xcodeproj/project.pbxproj - Je ne construis pas encore pour Android
• @semantic-release/github : attacher le CHANGELOG.md fichier à la libération 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 effectivement le bundle de l'application 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 fichier de changelog, un tag ou une release Github : tout est géré par défaut par semantic release, avec une configuration minimale.

Construction de nouveaux binaires avec XCode Cloud

Intégrer tout cela avec la construction de nouveaux versions du fichier d'application binaires est simple (je n'ai pas encore déployé 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.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 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.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 de client personnalisée déployée à partir d'une branche de release personnalisée, comme mentionné plus tôt.

Élaboration 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 mon pipeline de libération semantique standard, rapidement dans le délai du période d'essai de 14 jours, et le résultat est le suivant :

• Les numéros de versions de paquets sont générés automatiquement par la libération semantique et sont compatibles avec les Capgo serveurs
• La libération semantique déploie automatiquement les Capgo ensembles de paquets d'applications, en utilisant également les Capgo canaux
• Cela s'intègre bien avec les builds XCode Cloud des 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 également régulièrement avec Capgo.

J'espère ajouter une vérification pré-build plus efficace de Capgo dans ma configuration de libération semantique. bundle upload Prérequis

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 avec 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 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 développement).