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

1. Introduction

À Rapido Cloud (www.rapido.cloud), je développe une application mobile pour les clients Salesforce pour qu'ils puissent déployer facilement leur propre application mobile personnalisée sans avoir à 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 décrit ma conception, mes choix et ma mise en œuvre qui rendent Capgo possible. semantic-release un très bon choix sans réflexion pour gérer toutes les déploiements automatiquement via Github Actions. Toute cette chose 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 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 was rather afraid of the learning curve to make this successful but I got my app onto Apple TestFlight quite easily. I was then in position to use Capgo CapacitorUpdater to deploy my updates much faster.

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 !

Ainsi, Capgo CapacitorUpdater m'a aidé à mettre à jour mon application sur mon appareil mobile, en temps réel, 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 publication, et comment semantic-release s'y insère

Ainsi, 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.

Voici comment j'organise mon modèle de branchement et de publication

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 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 publication lesquelles peuvent être : production, branches de préversion (alpha, beta, nightlyet 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 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/stratégies-de-branche-git-en-2022

Une remarque 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 mineure, tandis que les fonctionnalités créeront une nouvelle version mineure. Il inclut également automatiquement le préfixe de préversion alpha, beta, etc. dans le numéro de version.

La mise en œuvre semantique génère le changelog à partir de vos commits, regroupant les correctifs et les fonctionnalités comme définis dans les commits conventionnels (voir https://www.conventionalcommits.org/fr/about) et configurés dans la mise en œuvre semantique.

It mettra également à jour toutes vos demandes de tirage de git (Github, dans mon cas) et les problèmes liés avec des commentaires les liant à la balise et à la mise en œuvre. Enfin, dans cette Github mise en œuvre, il attacherait des actifs comme des sources code, des binaires si nécessaire, etc. CHANGELOG.md, etc.

4. Branches, sorties, canaux dans semantic release et dans Capgo

Voici ce que je veux que semantic release fasse pour les déploiements Capgo.

Je veux que la mise à jour semantique génère le numéro de version.

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-version), et les leurs 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) les 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 paquets JavaScript suivent la « standard » semver « Semantic Versioning » (https://semver.org) qui semantic-release également suit (évidemment !)

Je suis donc ravi, et c'est un soulagement pour moi car j'utilise semantic-release extensively.

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

Je dois déployer une version préalable depuis des branches telles que alpha, beta, nightly mais également 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 œuvre semantique soutient également, donc je suis impatient de les faire fonctionner ensemble. Ces derniers s'intègrent également aux 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 semantic release sur les préversions ressemblent à 1.0.0-alpha.1. Les builds successifs sur cette branche incrémenteront 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 de mise en œuvre semantique et les préversions pour générer des versions de mon application avec Capgo canaux.

5. Comment puis-je utiliser Capgo pour publier mon application ?

Pour automatiser le déploiement de vos bundles d'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 d'upload. Parmi celles-ci, nous allons utiliser 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)
• La 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 semantic release + Capgo CapacitorUpdate

Enfin, comment cela s'insère-t-il tous ensemble ?

Les versions de l'application bundlées avec semantic release et Github Actions

Semantic release automation with Github Actions

La beauté de semantic release est que l'automatisation de la mise en production, sous forme d'un flux de travail de 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 branchessemantic release déclenchera une mise en production. Définissez CAPGO_APIKEY In votre répertoire, dans les secrets. Mettez à jour votre CAPGO_APPID Ici.

Le comportement de la mise en œuvre sémantique est défini dans son .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 configure les configurations des branches ("name), mappées au canal Capgo ("channel) et comment 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 sémantique sera x.y.z-development.n
  • les déploiements vers le alphaet alpha-nocapgo branches déployeront toutes les deux l'application sur le alphale canal, mais avec des noms de version de préversion différents
  • les déploiements vers les branches de développement dev-rupertou dev-paul seront déployés ensemble developmentcanal sur Capgo, tous avec le même developmentpré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 : du matériel standard de publication semantique - consultez leur documentation (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#format-de-message-de-commit)
• @semantic-release/release-notes-generator Générer le fichier de changelog. 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 release semantique ("package.json, CHANGELOG.md and ios/App/App.xcodeproj/project.pbxproj - Je n'ai pas encore construit pour Android)
• @semantic-release/github : attachez le CHANGELOG.md fichier à l'Github 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 de 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 changelog, une étiquette ou une mise à jour de Github, etc. : tout est géré par défaut par la mise à jour semantique, 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 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 CHANGELOG.md le 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 mis en place releaserc.json (oui, c'est une duplication manuelle) et puis, si je le voulais, je pourrais déployer une autre application AppStore pour chaque application cliente personnalisée déployée à partir d'une branche de version personnalisée, comme mentionné plus tôt.

Construction de fichiers d'application sur XCode Cloud avec des canaux Capgo

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 de la période d'essai de 14 jours, et le résultat est le suivant :

• Les numéros de version du bundle sont générés automatiquement par semantic release et sont compatibles avec les serveurs Capgo.
• la libération semantique déploye automatiquement les bundles d'application Capgo, en utilisant également les canaux Capgo
• cela s'intègre bien avec les builds de fichiers d'application XCode Cloud

É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 bundle upload prérequis dans ma configuration de release semantique.

J'ai maintenant un pipeline de release 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 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 partir à une nouvelle aventure en tant que solopreneur Salesforce avec mon Rapido Cloud offre de produits

https://linkedin.com/in/rbarrow https://www.linkedin.com/in/rbarrow.

Vous pouvez consulter nos offres Salesforce à https://www.rapido-companion.app and https://www.rapido.cloud Mise à jour en cours.

Continuez à partir de Comment Rapido Cloud gère la mise en forme de la mise à jour avec Capgo CapacitorUpdater.

Si vous utilisez Comment Rapido Cloud gère la mise en forme de la mise à jour avec Capgo CapacitorUpdater. pour planifier la livraison live update, 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, Fonctionnalités pour les détails d'implémentation dans Fonctionnalités, Comportement de mise à jour pour les détails d'implémentation dans le comportement de mise à jour. Types de mise à jour Pour les détails d'implémentation dans les types d'Update.