Comment Rapido Cloud gère la mise en production 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 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, 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 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 rendre les déploiements d'applications mobiles beaucoup plus simples, beaucoup plus rapides et flexibles que le processus standard d'Apple AppStore/Google PlayStore.

I avais plutôt 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'étais ensuite en position pour utiliser Capgo CapacitorUpdater pour déployer mes mises à jour beaucoup plus rapidement.

Mon premier besoin 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 de photos 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 !

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 publication, et comment semantic-release s'y insère

Alors maintenant que j'ai mon déploiement vers Capgo serveurs fonctionne 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 publication

Pour chaque application, qu'elle soit mobile, web ou Salesforce :

• la mise en œuvre a lieu sur feature/... se débranche de main, et elles sont fusionnées dans main qui 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)
• les déploiements sont déclenchés à partir de branches de version qui peuvent être : productiondes 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 fusion qui est fusionnée dans une branche de déploiement. Je n'utilise pas les déploiements déclenchés par tag 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 fonctionne semantic-release :

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, betaLes correctifs créeront une nouvelle version de patch, tandis que les fonctionnalités créeront une nouvelle version mineure.

Elle inclut également automatiquement le pré-lancement 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 (voirhttps://www.conventionalcommits.org/en/about

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.mdElle mettra également à jour toutes vos demandes de tirage de code (__CAPGO_KEEP_0__, dans mon cas) et les problèmes liés avec des commentaires les liant à la tag et à la release.

4. Branches, releases/prereleases, channels in semantic release and in Capgo

4. Les branches, les releases/pré-releases, les canaux dans semantic release et dans Capgo

Alors, ce que je veux que semantic release fasse pour les déploiements de __CAPGO_KEEP_0__ est le suivant.

Capgo have developed and documented their own version of the “Conventional Commits” standard-version __CAPGO_KEEP_0__ ont développé et documenté leur propre version de la « Conventional Commits » tool, avec leur repo forké standard-version (https://github.com/Cap-go/standard-versionet leurs propres capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionautant que capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionrepos. 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 fichiers de bundles JavaScript suivent la « standard » semver « Semantic Versioning » (https://semver.org semantic-release ) qui

suivent également (évidemment !) semantic-release de manière étendue.

Je souhaite également que semantic release 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 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 semantic release prend également en charge, donc je suis impatient de les faire travailler ensemble. Ces dernières s'insèrent également dans les différentes constructions de branches gérées par XCode Cloud (voir plus sur cela ci-dessous).

Les numéros de version Semver générés par semantic release sur les pré-lancements ressemblent à 1.0.0-alpha.1Les constructions successives sur cette branche incrémenteront le numéro de construction à 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é-lancements 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 bundle d'applications vers Capgo, vous devez utiliser la commande Capgo CLI bundle uploadType npx @capgo/cli@latest bundle upload --help pour obtenir les nombreuses options d'upload. 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 souhaitons 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. Mon setup de mise à jour de Capacitor avec semantic release et Capgo

Finalement, comment cela s'insère-t-il dans l'ensemble ?

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

Automatisation de la mise en production avec semantic release et Github Actions

La beauté de semantic release est que l'automatisation de la mise en production, sous forme d'un workflow d'action Github, 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 marge sur une branché listé dans branches, la mise à jour semantique déclenchera un déploiement. CAPGO_APIKEY Définir CAPGO_APPID dans les secrets de votre dépôt.

Mettre à 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 à jour semantique est défini dans sonname), mapped to the Capgo channel (channelVoici mes paramètres, expliqués ci-dessous :prereleasedéfinit la configuration des branches ( branch.prerelease = "development"), mappée au canal __CAPGO_KEEP_0__ ( x.y.z-development.n
  • ) et comment le numéro de version préversion sera appelé (", "). Par exemple, si", le numéro de version généré par la mise à jour semantique sera" et les déploiements vers le alphaet les branches déployeront l'application sur le alpha-nocapgo ou les deux déployeront sur le alphamais avec des noms de version de préversion différents
  • déployements vers les branches du développeur dev-rupertou dev-paul déployeront tous deux sur le developmentsur Capgo, tous avec le même mot-clé de préversion dans la version development: lors de la première étape de la mise en œuvre de la sérialisation, il vérifie qu'il a accès correctement à __CAPGO_KEEP_0__. J'espère ajouter une vérification d'authentification pour le __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ ici plus tard
• 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 https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formathttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator ici CHANGELOG.md
• @semantic-release/git : commitez les fichiers suivants qui ont été mis à jour par la construction Ionic de l'application et par le travail de la libération semantique (package.json, CHANGELOG.md et ios/App/App.xcodeproj/project.pbxproj - Je ne construis pas encore pour Android,
• @semantic-release/github : attachez le CHANGELOG.md fichier à la Github libération 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 changement, un Github tag ou libération, etc. : tout est géré par défaut par la libération semantique, avec une configuration minimale.

La construction de nouvelles versions binaires avec XCode Cloud

Intégrer tout cela avec la construction de XCode Cloud pour créer de nouvelles versions du fichier binaire de l'application est simple (Je ne déploie pas encore 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 branch que je souhaite utiliser pour cela (par exemple production)
• sur cette branch, 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 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, je définis 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 version 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 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 semantic release et sont compatibles avec les serveurs Capgo
• La mise en production automatique des bundles d'application Capgo par semantic release, en utilisant également les canaux Capgo
• Cela s'intègre bien avec les builds XCode Cloud de binaires d'applications

Étapes suivantes

Je me trouve actuellement dans la 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éalable plus performante de Capgo dans ma configuration de release semantique. bundle upload Je souhaite ajouter des prérequis de vérification préalable de __CAPGO_KEEP_0__ dans ma configuration de release semantique.

J'ai maintenant une 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 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 vais déployer une version gratuite de l'application sur l'AppStore pour les tests et https://www.rapido.cloud (en développement).

Continuez à partir de la façon dont Rapido Cloud gère la mise en œuvre de la mise à jour sémantique avec Capgo CapacitorUpdater

Si vous utilisez La façon dont Rapido Cloud gère la mise en œuvre de la mise à jour sémantique avec Capgo CapacitorUpdater pour planifier la livraison d'actualisations en direct, connectez-le 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 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.