Comment Rapido Cloud gère la mise en œuvre de la version sémantique avec Capgo CapacitorUpdater

1. Introduction

À Rapido Cloud (www.rapido.cloudJe développe une application mobile pour les clients Salesforce qui peuvent facilement déployer leur propre application mobile personnalisée sans 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, comme 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 un choix très réussi 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 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 pousse dans 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.

I avais une certaine 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 maintenant que j'ai 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'il s'agisse de mobile, web ou Salesforce :

• se déroule sur des branches dérivées 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 des fonctionnalités spécifiques pour les 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 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 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é sur la façon dont semantic-release fonctionne :

In une branche de déploiement, lorsqu'il est déclenché, semantic-release 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éfinis dans les commits conventionnels (voir https://www.conventionalcommits.org/en/about) et configurés 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 attache des éléments tels que des sources code, des binaires si nécessaire, etc. CHANGELOG.md4. Branches, releases/prereleases, canaux dans semantic release et dans __CAPGO_KEEP_0__

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

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 Je veux que semantic release génère le changelog à partir de mes 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. 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 fichiers de bundles 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 œuvre de la version sémantique 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éversion à partir de branches telles que alpha, beta, nightly par exemple, etc., mais aussi des versions spécifiques aux clients sur des branches telles que production-customer-jones, production-customer-doepar exemple, etc.

Capgo fournit la fonctionnalité des « canaux » qui est exactement ce que la mise en œuvre de la version sémantique prend également en charge, donc je suis enthousiasmé à les faire travailler ensemble. Ces derniers s'intègrent également avec les différents builds de branches gérés par XCode Cloud (voir plus en bas).

Les numéros de version Semver générés par la mise en œuvre de la version sémantique sur les préversions ressemblent à 1.0.0-alpha.1Le succès des builds successifs sur cette branche augmentera le numéro de build à 1.0.0-alpha.2par exemple, 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 la mise en œuvre de la version sémantique pour générer des versions de mon application avec les canaux Capgo.

5. Comment puis-je utiliser Capgo pour déployer mon 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)
• LE_CANAL 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_CLE_API est fournie par Capgo pour identifier de manière unique votre pipeline de CI/CD de connexion com.mystartup.mysuperapp)

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

6. Ma mise en œuvre de la release semantique + __CAPGO_KEEP_0__ CapacitorUpdate

Les versions de l'application bundlées avec la mise en œuvre de la release semantique et Github Actions

Les versions de l'application bundlées avec la mise en œuvre de la release semantique et Github Actions

L'automatisation de la release semantique 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 release semantique réside dans le fait 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 branche listée dans branches, la mise en production sera déclenchée par la mise en œuvre de la mise en production semantique. CAPGO_APIKEY Configurez CAPGO_APPID à vos secrets de votre dépôt.

Mettez à jour 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 mise en œuvre semantique est configuré dans son fichier de configuration.name), mapped to the Capgo channel (channelconfigure les branches (prerelease), mappées 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 vous souhaitez que le numéro de version généré par la mise en œuvre semantique soit « préversion » pour les mises en production sur le canal « __CAPGO_KEEP_0__ » alors que le numéro de version de préversion sera appelé « __CAPGO_KEEP_0__ » pour les mises en production sur le canal « __CAPGO_KEEP_0__ ». alphaet alpha-nocapgo les branches déployeront l'application sur le alphachaîne, mais avec des noms de version de préversion différents
  • les déploiements sur les branches de développement dev-rupertou dev-paul seront tous déployés sur la developmentchannel on Capgo, all with the same development: dans la première étape de la mise en œuvre semantique, il vérifie qu'il a accès correctement à la
• 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 __CAPGO_KEEP_1__https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator ici plus tard : les choses standard de la mise en œuvre semantique - voir leur documentation (https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format) : générer le fichier de changelog comme 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 effectivement l'application bundle 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 changement, 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 binaires avec XCode Cloud

Intégrer tout cela avec XCode Cloud pour construire de nouvelles versions du fichier binaire de l'application 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 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 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é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 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 fichiers 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 faisant également usage des Capgo canaux
• cela s'intègre bien avec les builds XCode Cloud de fichiers 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 déployer avec certitude 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 dans ma configuration de release semantique. bundle upload J'ai maintenant une pipeline de release semantique propre, simple et réplicable pour les futures applications mobiles 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 produits 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 vais déployer une version gratuite de l'application sur l'AppStore pour les tests Je vais mettre à jour régulièrement avec __CAPGO_KEEP_1__ pendant les tests et https://www.rapido.cloud (en développement).

Continuez de How Rapido Cloud gère la mise en production de Semantic Release avec Capgo CapacitorUpdater

Si vous utilisez 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’à 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, 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.