How Rapido Cloud verwalten Semantic Release mit Capgo CapacitorUpdater

1. Einleitung

Bei Rapido Cloud (www.rapido.cloud) entwickle ich eine mobile Anwendung für Salesforce-Kunden, damit sie ihre eigenen brandgeladenen mobilen Anwendungen leicht ohne die schwierigen Schleifen des Salesforce Mobile SDK oder des Salesforce Mobile Publisher bereitstellen können.

Ich habe diese mobile App auf einem modernen und "standard"-Plattform mit weit verbreiteten Komponenten und Werkzeugen entwickelt, einschließlich Ionic 8, Angular 18, TypeScript, Capacitor und jetzt Capgo CapacitorUpdater. Diese sind einfacher zu handhaben für Kunden, die Salesforce-Plattform-Spezifika wie Lightning Web Components nicht verwalten möchten; und es ist einfacher und günstiger für mich, Entwickler und Maintainer von Ionic + Angular mobilen Anwendungen zu rekrutieren.

Dieses Artikel erklärt meine Design, meine Entscheidungen und Implementierung, die Capgo und semantic-release ein sehr erfolgreicher No-Brainer für die automatische Verwaltung aller Bereitstellungen über Github Actions. Alles wurde während der schönen 14-tägigen kostenlosen Testzeit von Capgo CapacitorUpdater entworfen, getestet und dokumentiert.

2. Warum Capgo verwenden? Warum semantic-release verwenden?

Capgo CapacitorUpdater hat mich mit seiner Versprechung angezogen, die mobilen App-Bereitstellungen viel einfacher, viel schneller und flexibler zu machen als das Standard-Verfahren über Apple AppStore/Google PlayStore.

Ich war eher von der Lernkurve für dieses Projekt abgeschreckt, aber ich konnte mein App auf Apple TestFlight leicht einrichten. Dann war ich in der Lage, Capgo CapacitorUpdater zu verwenden, um meine Updates viel schneller zu deployen.

Mein erster Anspruch und Testfall war, meine App für mich selbst zu deployen, um meine App als echte mobile App auf meinem eigenen Handy zu testen, anstatt in einem mobilen Emulator oder in einem Simulator über die Nexus-Mobilbrowser von IIonic zu testen. Das ist, weil meine App native Funktionen wie Geolocation oder Zugriff auf die Foto-Galerie und Kamera verwendet. Ohne die Erfahrung von der Testung einer Capacitor mobilen App war ich nicht sicher, ob alles richtig funktionieren würde : nichts besser als die echte App in realen Bedingungen zu testen !

So Capgo CapacitorUpdater halfierte mir die Aktualisierung meiner Anwendung auf meinem Mobilgerät, live, 1 Minute nach dem Speichern einer neuen Funktion oder eines Fixes in meiner Quelle code : so erleichternd und so flexibel und leicht zu konfigurieren !

3. Meine Zweig- und Veröffentlichungsmodell und wie semantic-release hineinpasst

So jetzt habe ich meine Lieferung an Capgo Server korrekt funktionieren, ich muss diese automatisieren und in mein CI/CD-Pipeline einfügen.

Dies ist, wie ich mein Zweig- und Veröffentlichungsmodell organisiere

Für jede Anwendung, sei es mobile, Web oder Salesforce :

• Die Entwicklung findet statt auf feature/... Zweigen ab main, und sie werden in main das ist der Referenzpunkt für die meisten Entwicklungszweige, außerhalb von Wartung und spezifischen Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten)
• Die Bereitstellung wird ausgelöst von Veröffentlichungszweigen welche möglicherweise : productionPräversionszweige (alpha, beta, nightlyetc.) und auch Kunden- oder Kontextspezifische Zweige für individuelle Lieferungen
• Deployments werden durch einen Pull-Request ausgelöst wird in einen Deployment-Zweig eingebunden. Ich verwende keine tag-gesteuerten Deployments, da semantic-release die Tags und alles andere für mich verwaltet.

Im Grunde ist das Gitlab-Flow :

Gitlab-Flow - Quelle https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

Eine Randbemerkung zu wie semantic-release funktioniert :

In einem Deployment-Zweig, wenn semantic-release ausgelöst wird, wird es automatisch die neue Versionsnummer auf diesem Zweig berechnen, je nach Versionsnummer des vorherigen Tags auf dem Zweig und den gelieferten Fixes oder Features. Fixes werden eine neue Patchversion erzeugen, während Features eine neue Minorversion erzeugen. Es fügt auch automatisch die Präversions alpha, betaetc. in die Versionsnummer ein.

Semantic release generiert die Änderungsliste aus Ihren Commits, gruppiert Fixes und Features wie in conventioellen Commits (siehe https://www.conventionalcommits.org/en/about) und konfiguriert in semantic release.

Es wird auch alle Ihre Git (Github, in meinem Fall) fusionierten Pull-Anforderungen und damit verbundenen Probleme mit Kommentaren aktualisieren, die sie mit der Versionsnummer und der Veröffentlichung verbinden. Schließlich wird in dieser Github Veröffentlichung es auch Assets wie Quellcode (code), Binärdateien, wenn nötig, etc. anfügen. CHANGELOG.md4. Zweige, Veröffentlichungen/Vorabveröffentlichungen, Kanäle in semantic release und in __CAPGO_KEEP_0__

So, was ich von semantic release für Capgo-Deployments möchte, ist Folgendes.

So what I want semantic release to do for Capgo deployments is the following.

__CAPGO_KEEP_0__ haben ihre eigene Version der „Conventional Commits“-Tool entwickelt und dokumentiert, mit ihrem forkierten Repository

https://Capgo.com/Cap-go/standard-version standard-version ), und ihre eigene standard-version (4. Branches, releases/prereleases, channels in semantic release und in githubSo, was ich von semantic release für __CAPGO_KEEP_0__-Deployments möchte, ist Folgendes. capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionzusammen mit capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionRepos. Sie haben auf ihrem Blog die Versionsnummerierung von Capgo in ihren Bereitstellungen dokumentiert (https://capgo.app/blog/how-version-work-in-capgo/)JavaScript-Bundles folgen der 'standard' semver 'Semantic Versioning' (https://semver.org semantic-release )

was auch (offensichtlich !) semantic-release Das ist großartig und ist für mich eine Erleichterung, weil ich __CAPGO_KEEP_1__

extensiv verwende. Ich möchte auch, dass semantic release App-Bereitstellungen auf verschiedenen Kanälen generiert

As erwähnt, muss ich eine Vorkonfiguration aus Zweigen wie alpha, beta, nightly etc., aber auch Kunden spezifische Versionen auf Zweigen wie production-customer-jones, production-customer-doe, etc.

Capgo bietet die „Kanäle“-Funktion, die genau das ist, was auch semantic release unterstützt, also bin ich begeistert, sie zusammenzubringen. Diese passen auch zu den verschiedenen Zweig-Builds, die von XCode Cloud verwaltet werden (siehe mehr dazu unten).

Semver-Versionen, die von semantic release auf Vorkonfigurationen generiert werden, sehen wie 1.0.0-alpha.1. Bei aufeinanderfolgenden Builds auf diesem Zweig wird die Buildnummer um 1.0.0-alpha.2, etc. zu erhöht. Obwohl dies nicht explizit dokumentiert ist, unterstützen diese Versionen Capgo, was für mich großartige Nachricht ist : Ich werde semantic release-Kanäle und Vorkonfigurationen verwenden, um Versionen meiner App mit Capgo-Kanälen zu generieren.

5. Wie kann ich Capgo verwenden, um meine Anwendung zu veröffentlichen ?

Um die Bereitstellung Ihrer App-Bundles auf Capgo zu automatisieren, müssen Sie das Capgo CLI-Kommando verwenden bundle upload. Typ npx @capgo/cli@latest bundle upload --help um die zahlreichen Upload-Optionen zu erhalten. Unter denen werden wir die folgenden verwenden :

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

• CHANNEL ist der Capgo-Kanal, auf den wir deployen möchten (z.B alpha)
• VERSION wird durch semantic release generiert (z.B. 1.0.0-alpha.1)
• CAPGO_APIKEY wird von Capgo zur eindeutigen Identifizierung Ihres CI/CD-Pipeline-Logins bereitgestellt
• CAPGO_APPID wird von Capgo zur eindeutigen Identifizierung Ihrer Anwendung (z.B. com.mystartup.mysuperapp)

6. Meine semantic release + Capgo CapacitorUpdate-Einrichtung

Schließlich passt sich alles zusammen?

Mit semantic release und Github Actions erstellte App-Bundle-Versionen

Semantic release-Automatisierung mit Github Actions

Die Schönheit von semantic release besteht darin, dass die Bereitstellungsautomatisierung in Form einer Github Actions-Arbeitsablauf sehr einfach ist. Dies wird auf anderen CI/CD-Plattformen sehr ähnlich aussehen.

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

Dies installiert einfach die NodeJS-Umgebung und ruft dann semantic release auf.

Für jeden Merge auf einer in branches, semantic release wird eine Bereitstellung auslösen. Set CAPGO_APIKEY in Ihren Repository-Secrets. Aktualisieren Sie Ihren CAPGO_APPID hier.

Die Verhaltensweise von semantic release wird in ihrem .releaserc.json Konfigurationsdatei festgelegt. Hier sind meine Einstellungen, die unten erläutert werden :

// .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 legt die Konfiguration von Branchen (name), die auf den Capgo Kanal (channel) und wie die Voreinstellung der Versionsnummer genannt wird (prerelease) fest. branch.prerelease = "development"Beispiel: Wenn x.y.z-development.n
  • , wird die Versionsnummer von semantic release alphaDeployments auf das alpha-nocapgo und die Branches werden beide die App auf das alphaKanal, aber mit anderen Vornamen für Vorabversionen in der Versionsnummer
  • Zu den Entwicklerzweigen dev-rupertoder dev-paul werden beide auf developmentKanal auf Capgo, alles mit der gleichen developmentVorabversionsschlüsselwort in der Versionsnummer
• verifyConditions : in der ersten Phase der semantischen Veröffentlichung überprüft es, ob es den richtigen Zugriff auf Github hat. Ich hoffe, ich kann hier später eine Authentifizierungsprüfung für den Capgo CLI einfügen
• @semantic-release/commit-analyzer : Standard-Semantik-Veröffentlichungs-Stuff - siehe ihre Dokumentation (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator : Erstelle das Changelog-File als CHANGELOG.md
• @semantic-release/git : Füge die folgenden Dateien hinzu, die durch die Ionic-Build des Anwendungs und durch die semantische Veröffentlichungsarbeit aktualisiert wurden (package.json, CHANGELOG.md und ios/App/App.xcodeproj/project.pbxproj - Ich baue noch nicht für Android, noch nicht)
• @semantic-release/github : füge dem __CAPGO_KEEP_0__-Release als Asset CHANGELOG.md file to the Github release as an asset
• @semantic-release/exec) und dann effektiv die App-Bundle auf den __CAPGO_KEEP_0__-Servern zu deployen (prepareCmdSie werden feststellen, dass es keine Umstände gibt, wie wir die Versionsnummer berechnen und erhöhen möchten, wie wir eine Changelog generieren, einen Capgo-Tag oder -Release erstellen müssen, etc. : Alles wird von semantic release standardmäßig gehandhabt, mit minimaler Konfiguration.publishCmd)

You will notice that their is no fiddling around with explaining how we want the version number to be calculated and incremented, how we need to generate a changelog, a Github tag or release, etc. : everything is handled by default by semantic release, with minimal configuration.

Integrieren Sie all das mit XCode Cloud, um neue Versionen des Anwendungsbinärs zu erstellen, ist einfach (Ich baue noch nicht auf Google Play, aber die Build sollte ähnlich sein) :

Ich habe einen XCode Cloud-Prozess eingerichtet, der gebaut, wenn es eine Änderung auf der von mir gewünschten Branch gibt (z.B.

• auf dieser Branch, habe ich XCode Cloud eingerichtet, damit es nur gebaut, wenn der production)
• Datei aktualisiert wird. Dies wird aktualisiert, nachdem jede Version durch semantic release generiert wurde. CHANGELOG.md Ich kann Builds auf verschiedenen Branches auslösen, um die Bereitstellung für verschiedene Kanäle zu simulieren. In jeder Konfiguration von XCode Cloud-Build auf einem anderen Branch, setze ich eine Umgebungsvariable manuell mit dem Wert von
• ]} branch.channel in der App releaserc.json (ja, das ist eine manuelle Duplikation) und dann, wenn ich wollte, könnte ich für jede benutzerdefinierte Kundenanwendung, die aus einer benutzerdefinierten Release-Zweig bereitgestellt wird, wie zuvor erwähnt, eine andere AppStore-Anwendung bereitstellen.

Binärdateien von Apps auf XCode Cloud mit Capgo-Kanälen erstellen

7. Fazit

Zusammenfassend bin ich sehr glücklich, Capgo CapacitorUpdater in meine Standard-Semantik-Release-Pipeline integriert zu haben, schnell innerhalb der Verzögerung der 14-Tage-Testzeit und das Ergebnis ist wie folgt :

• Die Versionszahlen von Bundeln werden automatisch durch Semantik-Release generiert und sind mit den Capgo-Servern kompatibel.
• Semantik-Release deployt Capgo-Anwendungs-Bundles automatisch, macht auch Gebrauch von Capgo-Kanälen
• Das passt gut in die XCode Cloud-Builds von Anwendungs-Binärdateien

Zukünftige Schritte

Ich bin derzeit in der Entwicklungsphase dieses Apps. Ich werde es schnell den Testern über TestFlight (für iOS) zur Verfügung stellen. Da ich die Macht von Capgo kenne, werde ich sicherlich eine kostenlose Version der App auf dem AppStore für Tests bereitstellen, die regelmäßig mit Capgo aktualisiert wird. Dann werde ich eine weitere (bezahlte) Version der App auf dem AppStore bereitstellen, unter einer anderen Aufzeichnung, und auch regelmäßig mit Capgo aktualisieren.

Ich hoffe, ich kann bessere Prüfungen vor der Erstellung von Capgo hinzufügen. bundle upload Voraussetzungen in meine semantische Release-Konfiguration einfügen.

Ich habe jetzt eine saubere, einfache und reproduzierbare semantische Release-Pipeline für zukünftige mobilen Apps, die mit Ionic + Angular + Capacitor entwickelt wurden.

Verfasser - Rupert Barrow

Mit über 22 Jahren Erfahrung bei Salesforce, als Kunde und Nutzer, als Partner und Integrator, Architekt, Entwickler, Geschäftsanalyst und Berater habe ich Erfahrung gesammelt. Ich gründete und leitete gemeinsam Altius Services als COO und CTO für 13 Jahre, ein erfolgreicher Salesforce-Partner für Systemintegration in Frankreich, bevor ich mich auf eine neue Abenteuer als Salesforce-Solopreneur mit meinem Rapido Cloud Produktangebot

Sie können mich auf LinkedIn finden unter https://linkedin.com/in/rbarrow.

Sie können unsere Salesforce-Angebote auf https://www.rapido-companion.app und https://www.rapido.cloud (unter Entwicklung).

Weitermachen von How Rapido Cloud Semantic Release mit Capgo CapacitorUpdater

Wenn Sie How Rapido Cloud Semantic Release mit Capgo CapacitorUpdater zur Planung der Live-Update-Übermittlung verwenden, verbinden Sie es mit Capgo Live Updates für den Produktworkflow in Capgo Live Updates, Übersicht für die Implementierungsdetails in Übersicht, Funktionen für die Implementierungsdetails in Funktionen Aktualisierungsverhalten für die Implementierungsdetails in Updateverhalten und Update-Typen für die Implementierungsdetails in Update-Typen.