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 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 que le processus standard de livraison par l'Apple AppStore/Google PlayStore. C'est mon premier application mobile que je pousse vers les magasins, ayant concentré mon attention dans le passé sur les applications web, généralement développées sur l'expérience Salesforce Cloud.

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 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 !

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

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

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 mainqui 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 les livraisons personnalisées (en savoir plus ci-dessous)
• les déploiements sont déclenchés à partir de 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 livraisons personnalisées ou contextuelles
• Les déploiements sont déclenchés par une demande de tirage. Je ne 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 la stratégie de Gitlab Flow :

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

Remarque secondaire sur la façon dont fonctionne semantic-release :

Lorsque semantic-release est déclenché dans une branche de déploiement, 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éent une nouvelle version de patch, tandis que les fonctionnalités créent une nouvelle version mineure. Il inclut également automatiquement le pré-lancement alpha, betaetc. 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é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.md, etc.

4. Branches, sorties/préversions, canaux dans la mise en œuvre de la version semantique et dans Capgo

Alors, pour les déploiements de Capgo, je veux que la mise en œuvre de la version semantique fasse les choses suivantes.

Je veux que la mise en œuvre de la version semantique 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 dépôt standard-version (https://github.com/Cap-go/standard-versionet leur propre capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionainsi que capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. They have documented on their blog the version scheme used by Capgo in their deployemnts (https://capgo.app/blog/how-version-work-in-capgo/) les bundles JavaScript suivent le « standard » semver « Semantic Versioning » (https://semver.org) qui semantic-release suit également (évidemment !)

C'est donc super, et c'est un soulagement pour moi car je utilise semantic-release intensivement.

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 etc., mais également des versions spécifiques pour les clients sur des branches telles que production-customer-jones, production-customer-doe etc.

Capgo fournit la fonctionnalité des « canaux » qui correspond exactement à ce que semantic release prend en charge également, donc je suis impatient de les faire travailler ensemble. Ces derniers s'intègrent également avec 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. Même si ce n'est pas documenté explicitement, ces numéros de version 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 déployer mon 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 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 vers lequel 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. Ma mise en œuvre de la release semantique + Capgo CapacitorUpdate

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

Les versions de l'application bundle construites avec la release semantique et Github Actions

L'automatisation de la release semantique avec Github Actions

La beauté de la release semantique réside dans le fait 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 release semantique.

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

Mettez à jour votre fichier de configuration ici. (Ici). .releaserc.json le 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 fixe la configuration des branches (name), mapped to the Capgo channel (channel) et la façon dont le numéro de version de préversion sera appelé (prerelease). Par exemple, si branch.prerelease = "development", le numéro de version généré par la mise en œuvre semantique sera x.y.z-development.n
  • les déploiements vers le alphaet alpha-nocapgo les branches seront toutes deux déployées sur le alphamais avec des noms de préversion différents dans le numéro de version
  • les déploiements vers les branches de développement dev-rupertou dev-paul seront déployés tous les deux sur le developmentcanal sur Capgo, tous avec le même developmentmot-clé de préversion dans le numéro de version
• 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 correct pour __CAPGO_KEEP_0__. J'espère ajouter une vérification d'authentification pour le https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator : choses standard de la mise en œuvre de la version sémantique - voir leur documentation ( CHANGELOG.md
• @semantic-release/git https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format package.json, CHANGELOG.md : générer le fichier de changelog comme ios/App/App.xcodeproj/project.pbxproj : 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 version sémantique (
• @semantic-release/github et CHANGELOG.md file to the Github release as an asset
• @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 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 tag ou une release Github, etc. : tout est géré par défaut par semantic release, avec une configuration minimale.

Construction de nouvelles binaires avec XCode Cloud

Intégrer tout cela avec la construction de nouvelles versions de l'application binaire par XCode Cloud 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 une variable d'environnement manuellement avec la valeur de branch.channel configurée 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 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 libération 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 libération semantique et sont compatibles avec les Capgo serveurs
• La libération semantique déploie automatiquement les Capgo bundles 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 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é-build plus efficace de Capgo dans ma configuration de libération semantique. bundle upload J'ai maintenant une pipeline de libération 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.

Étapes suivantes

I dispose d'une expérience de plus de 22 ans sur 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 produit d'offre.

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 context: Page/area: Site web de marketing Capgo. Rôle: Étiquette de navigation ou élément de navigation court. Vu dans: page trust.astro. Clé de message `et` (Et). https://www.rapido.cloud

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

Continuez à partir de Comment Rapido Cloud gère la mise en œuvre sémantique avec __CAPGO_KEEP_0__ CapacitorUpdater (mise à jour de Capacitor). How Rapido Cloud gère la mise en production de Semantic Release avec Capgo CapacitorUpdater pour planifier la livraison d'actualisations en direct, connectez-l’avec Capgo Mises à jour en direct pour le flux de travail du produit dans Capgo Mises à jour en direct Vue d'ensemble pour les détails d'implémentation dans Vue d'ensemble Fonctionnalités pour les détails d'implémentation dans Fonctionnalités Comportement de mise à jour pour les détails d'implémentation dans Comportement de mise à jour, et Types de mise à jour pour les détails d'implémentation dans Types de mise à jour.