How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

1. Introduction

À Rapido Cloud (www.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 have developed this mobile app on a modern and “standard” platform with widespread components and tools including Ionic 8, Angular 18, TypeScript, Capacitor and now Capgo CapacitorUpdater. These are more simple to handle for clients who do not want to manage Salesforce platform specifics such as Lightning Web Components; and its easier and cheaper for me to recruit developers and maintainers of Ionic + Angular mobile applications.

This article explains my design, my choices and implementation which make Capgo and semantic-release a very successful no-brainer for managing all deployments automatically via Github Actions. All this was designed, tested and documented during the nice 14-day free trial period of Capgo CapacitorUpdater.

2. Why use Capgo ? Why use semantic-release ?

Capgo CapacitorUpdater attracted me with its promise to make mobile app deployments much more simple, much more rapid and flexible than going through the standard Apple AppStore/Google PlayStore delivery process. This is my first mobile application which I am pushing to the stores, having concentrated in the past on web apps, usually developed on the Salesforce Experience Cloud.

I avais peur de la courbe d'apprentissage pour rendre cela réussi, mais j'ai réussi à 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 critère 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 si tout allait fonctionner correctement : rien de mieux que de tester l'application réelle, dans des conditions réelles !

Alors 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

Alors que j'ai maintenant ma livraison vers 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 :

• se déroule sur se déroule sur des feature/... et elles sont fusionnées dans mainqui 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 des livraisons personnalisées (en savoir plus ci-dessous) main développement
• 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 n'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

Un petit côté-merci sur la façon dont semantic-release fonctionne :

In 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 tag précédent sur la branche et des correctifs ou fonctionnalités livrés. 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 comme défini dans les commits conventionnels (voir https://www.conventionalcommits.org/en/about) et configuré dans semantic release.

Ce processus met é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 tag et à la release. Enfin, dans cette Github release, il attachera des éléments tels que des sources code, des binaires si nécessaire, etc. CHANGELOG.md, etc.

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

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

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 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) 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-fonctionnent-les-versions-dans-capgo/)les paquets JavaScript suivent la « standard » semver « Semantic Versioning » (https://semver.org semantic-release ) qui

suivent également (évidemment !) semantic-release étendument.

Je veux également que la mise en production semantique génère des déploiements d'applications sur différents canaux.

Comme mentionné ci-dessus, j'ai besoin de déployer des versions de pré-lancement à partir de branches telles que alpha, beta, nightly par exemple, 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 production semantique prend également en charge, donc je suis impatient de les faire travailler ensemble. Ces derniers s'intègrent également aux différentes constructions de branches gérées par XCode Cloud (voir plus en bas).

Les numéros de version Semver générés par la mise en production semantique sur les pré-lancements ressemblent à 1.0.0-alpha.1. Les constructions successives sur cette branche incrémenteront le numéro de construction à 1.0.0-alpha.2, etc. Même si ces numéros de version ne sont 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é-lancements de la mise en production semantique 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.

npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID

• CHANNEL is the Capgo channel to which we want to deploy (eg alpha)
• CHANNEL est le __CAPGO_KEEP_0__ canal auquel nous souhaitons déployer (par exemple 1.0.0-alpha.1)
• CAPGO_APIKEY is provided by Capgo to uniquely identify your CI/CD pipeline login
• CAPGO_APIKEY est fourni par Capgo pour identifier de manière unique votre pipeline de CI/CD de connexion com.mystartup.mysuperapp)

Capgo_APPID est fourni par __CAPGO_KEEP_1__ pour identifier de manière unique votre application (par exemple

6. Ma mise en œuvre de la version sémantique + __CAPGO_KEEP_0__ CapacitorUpdate

Les versions de l'application bundlées créées avec la mise en œuvre de la version sémantique et Github Actions

Les versions de l'application bundlées créées avec la mise en œuvre de la version sémantique et Github Actions

Automatisation de la mise en œuvre de la version sémantique avec Github Actions

# ./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 }}

La beauté de la mise en œuvre de la version sémantique est que l'automatisation de la mise en œuvre, sous forme d'un flux de travail __CAPGO_KEEP_0__ Actions, est très simple. Cela ressemblera beaucoup aux autres plateformes de CI/CD .

For chaque mérge sur une branché listé dans branches, la mise en production sera déclenchée par la release semantique. CAPGO_APIKEY Configurez CAPGO_APPID dans les secrets de votre dépôt.

Actualisez 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 :
  • branches Le comportement de la release semantique est défini dans sonname), mapped to the Capgo channel (channelconfigure les branches (prerelease), mappé au canal (« branch.prerelease = "development") et comment le numéro de version de préversion sera appelé (« x.y.z-development.n
  • ). Par exemple, si « major » est choisi, le numéro de version généré par la release semantique sera « major.0.0-0 » et les mises en production seront effectuées sur le canal « alphaet alpha-nocapgo les branches déployeront l'application sur le alphachaîne, mais avec des noms de version de préversion différents
  • ou dev-rupertles déploiements sur les branches de développement dev-paul ou developmentchannel on Capgo, all with the same developmentla chaîne sur __CAPGO_KEEP_0__, tous avec le même
• 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 : dans la première étape de la mise en œuvre sémantique, il vérifie qu'il a accès correct à __CAPGO_KEEP_0__. J'espère ajouter une vérification d'authentification pour le __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ ici plus tardhttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format CHANGELOG.md
• @semantic-release/git : commitez les fichiers suivants qui ont été mis à jour par la build Ionic de l'application et par le travail de la mise en production semantique (package.json, CHANGELOG.md et ios/App/App.xcodeproj/project.pbxproj - Je n'ai pas encore construit pour Android
• @semantic-release/github : attachez le CHANGELOG.md fichier à la Github mise en production comme un élément
• @semantic-release/exec: utilisez ces 2 commandes pour préparer la construction de l'application (prepareCmd) et puis construire et déployer efficacement 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 Github tag ou une mise en production, etc. : tout est géré par défaut par la mise en production semantique, avec une configuration minimale.

Construire de nouvelles versions binaires avec XCode Cloud

Intégrer tout cela avec la construction de nouvelles versions de l'application binaire avec XCode Cloud est simple (Je n'ai pas encore déployé sur Google Play, mais cette construction devrait être similaire) :

• Je configure 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, je configure XCode Cloud pour construire uniquement lorsque le CHANGELOG.md le fichier est mis à jour. Cela est mis à jour après chaque version générée par la mise en release semantique
• Je peux déclencher des builds sur différentes branches pour simuler la mise en production pour différentes 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 configuré en 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 mise en release 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 mise en 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 des bundles sont générés automatiquement par la mise en release semantique et sont compatibles avec les Capgo serveurs
• la mise en release semantique déploye automatiquement les bundles d'applications Capgo, en utilisant également les Capgo canaux
• cela s'intègre bien avec les builds XCode Cloud de binaires d'applications

Étapes suivantes

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

J'espère ajouter une vérification préalable plus efficace de Capgo dans ma configuration de release semantique. bundle upload Je dispose maintenant d'une pipeline de release semantique propre, simple et réplicable pour les applications mobiles futures développées avec Ionic + Angular + __CAPGO_KEEP_0__.

I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.

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 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 sur nos offres Salesforce à https://www.rapido-companion.app.

Je suis actuellement en phase de développement de cette application. Je vais la rendre rapidement disponible aux testeurs via TestFlight (pour iOS). 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_KEEP_1__ pendant les tests. et https://www.rapido.cloud (en développement).

Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

Si vous utilisez How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater pour planifier la livraison d'actualisations en direct, connectez-l’avec Capgo Live Updates for the product workflow in Capgo Live Updates, Vue d'ensemble pour les détails d'implémentation dans Vue d'ensemble, Caractéristiques pour les détails d'implémentation dans les fonctionnalités, Mise à jour du comportement pour les détails d'implémentation dans la mise à jour du comportement, et Types de mise à jour pour les détails d'implémentation dans les types de mise à jour.