1. Einleitung
Bei 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 ein sehr erfolgreiches Low-Hang-Frucht für die automatische Verwaltung aller Bereitstellungen über Github Actions ermöglicht. 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 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 !
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 meinem Quellcode code : so erleichternd und so flexibel und leicht zu konfigurieren !
3. Mein Branching- und Release-Modell und wie semantic-release hineinpasst
Jetzt habe ich meine Lieferung auf Capgo-Servern korrekt eingerichtet, ich muss dies automatisieren und in meine CI/CD-Pipeline einfügen.
Dies ist meine Organisation meines Branching- und Release-Modells
Für jede Anwendung, sei es mobile, Web oder Salesforce :
- Entwicklung wird durchgeführt auf
feature/...Zweigen abmain, und sie werden inmainwelches das Referenzpunkt für die meisten Entwicklungsbranchen ist, außerhalb von Wartung und spezifischen Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten) - Deployments werden ausgelöst aus Release-Zweigen welche möglicherweise :
production, Vorabversionen (alpha,beta,nightly, usw.) und auch Kunden- oder Kontextspezifische Zweig für benutzerdefinierte Lieferungen - Deployments werden durch einen Pull-Request ausgelöst Deployments werden durch einen Pull-Request ausgelöst, da ich keine tag-gesteuerten Deployments verwende, da semantic release die Tags und alles andere für mich verwaltet.
Im Grunde ist dies der Gitlab Flow :
Gitlab Flow - Quelle https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Eine Nebenbemerkung 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 erstellen, während Features eine neue Minorversion erstellen. Es wird auch automatisch die Vorabversion alpha, beta, usw. in der Versionsnummer einbeziehen.
Semantic release generiert die Änderungsliste aus Ihren Commits, gruppiert Fixes und Features wie in conventional Commits (siehe https://www.conventionalcommits.org/de/ueber) und konfiguriert in 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. Zweige, Releases/Vorversionen, Kanäle in semantic release und in Capgo
So was ich von semantic release für Capgo-Deployments erwarten möchte, ist Folgendes.
Ich möchte, dass semantic release die Versionsnummer generiert.
Capgo have developed and documented their own version of the “Conventional Commits” standard-version Binärdateien falls erforderlich usw. erfolgen. standard-version (https://github.com/Cap-go/standard-version__CAPGO_KEEP_0__ capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) sowie auch capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-Plugin-Standardversion) Repositories. Sie haben auf ihrem Blog die Versionsnummerierung beschrieben, die Capgo in ihren Bereitstellungen verwendet (https://capgo.app/blog/wie-versionen-in-capgo-funktionieren/) JavaScript-Bundles folgen der 'standard' semver 'Semantic Versioning' (https://semver.org) which semantic-release auch folgt (natürlich !)
Das ist großartig und eine Erleichterung für mich, da ich semantic-release extensively.
Ich möchte auch, dass semantic release App-Deployments auf verschiedenen Kanälen generiert
As erwähnt oben, muss ich eine Vorschauversion von 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 unterstützt, was auch semantic release unterstützt, also bin ich begeistert, sie zusammenzubringen. Diese passen auch zu den verschiedenen Zweig-Builder, die von XCode Cloud verwaltet werden (siehe mehr darüber unten).
Semver-Versionen, die von semantic release auf Vorschauversionen generiert werden, sehen wie 1.0.0-alpha.1Successive Builds auf diesem Zweig werden die Buildnummer um eins erhöhen auf 1.0.0-alpha.2, etc. Obwohl dies nicht explizit dokumentiert ist, werden diese Versionsnummern von Capgo unterstützt, was großartige Nachrichten für mich ist: Ich werde semantic release-Kanäle und Vorschauversionen 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 zu Capgo zu automatisieren, müssen Sie den Capgo CLI-Befehl verwenden bundle upload. Typen 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-Pipelines-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-Action-Workflow 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 branchessemantic release wird für jeden Merge auf einer in CAPGO_APIKEY In Ihrem Repository-Schlüssel.
Aktualisieren Sie Ihr CAPGO_APPID Hier.
Die Verhaltensweise von semantic release wird in ihrem .releaserc.json Konfigurationsdatei.
Hier sind meine Einstellungen, wie unten erklärt:
// .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:branchesKonfiguriert die Verhaltensweise der Zweige (name), die dem Capgo Kanal (channel) und wie die Versionsnummer der Vorkonfiguration genannt wird ("prereleaseBeispielsweise, wennbranch.prerelease = "development"Die von semantic release generierte Versionsnummer wirdx.y.z-development.n- Deployments auf
alphaandalpha-nocapgoZweige werden beide die App auf dasalphaKanal, aber mit unterschiedlichen Voreinstellungen in der Versionsnummer - Implementierungen auf den Entwicklerzweigen
dev-rupertoderdev-paulwerden beide auf dendevelopmentKanal auf Capgo deployen, alle mit derselbendevelopmentVoreinstellungs-Schlüsselwort in der Versionsnummer
verifyConditions: Im ersten Stadium der semantischen Veröffentlichung überprüft es, ob es die richtigen Zugriffsrechte auf Github hat. Ich hoffe, ich kann eine Authentifizierungsprüfung für den Capgo CLI hier später hinzufügen@semantic-release/commit-analyzer: Standardmäßige semantische Veröffentlichung - 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 alsCHANGELOG.md@semantic-release/gitDie folgenden Dateien werden mit dem Ionic-Build der Anwendung und durch die Arbeit mit semantic release aktualisiert und werden daher mit dem Commit übernommen:package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android, noch nicht)@semantic-release/github: füge demCHANGELOG.mdDatei als Asset zur Github-Veröffentlichung hinzu@semantic-release/exec: verwende diese 2 Befehle, um die App-Build vorzubereiten (prepareCmd) und dann effektiv die App-Bundle auf die Capgo-Server zu deployen (publishCmd)
Sie werden feststellen, dass keine Zeit damit verbracht wird, zu erklären, wie wir die Versionsnummer berechnen und erhöhen möchten, wie wir eine Änderungsliste, eine Github-Marke oder -Veröffentlichung generieren müssen, usw. : Alles wird von semantic release standardmäßig mit minimaler Konfiguration gehandhabt.
Erstellung neuer Binärdateien mit XCode Cloud
Integrieren Sie alle diese Funktionen mit der Erstellung neuer Versionen des Anwendungsbinärs mit XCode Cloud. (Ich baue noch nicht auf Google Play, aber die Build sollte ähnlich sein) :
- Ich stelle einen XCode Cloud-Prozess ein, um zu bauen, wenn es eine Änderung auf der von mir gewünschten Branch gibt (z.B.
production) - auf dieser Branch setze ich XCode Cloud ein, um nur zu bauen, wenn die
CHANGELOG.mdDatei aktualisiert wird. Dies wird nach jeder von semantic release generierten Version aktualisiert - 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 der
branch.channelsetzt inreleaserc.json(ja, dies ist eine manuelle Duplikation) und dann, wenn ich wollte, könnte ich ein anderes AppStore-Anwendungsprogramm für jede benutzerdefinierte Kundenanwendung bereitstellen, die aus einer benutzerdefinierten Release-Zweig bereitgestellt wird, wie bereits erwähnt.
Erstellen von App-Dateien auf XCode Cloud mit Capgo-Kanälen
Zusammenfassend bin ich sehr glücklich, __CAPGO_KEEP_0__ CapacitorUpdater in meine Standard-Semantik-Release-Pipeline integriert zu haben, schnell innerhalb der Verzögerung der 14-Tage-Testdauer, und das Ergebnis ist wie folgt:
In conclusion, I am very happy to have been able to integrate Capgo CapacitorUpdater into my standard semantic release pipeline, rapidly within the delay of the 14-day trial period, and the result is the following :
- Die Versionszahlen der Pakete werden automatisch von semantic release generiert und sind mit den Capgo-Servern kompatibel.
- semantic release deployt automatisch Capgo Anwendungs- Bundle, nutzt auch Capgo Kanäle
- dies passt gut zu XCode Cloud-Builds von Anwendungsbinären
Nächste Schritte
I am currently in the development phase of this app. I will quickly make it available to testers through TestFlight (for iOS). Considering the power of Capgo, I will most certainly deploy a free version of the app to the AppStore for tests, which will be updated regularly with Capgo during tests. I will then deploy another (paid) version of the app on the AppStore, under another record, and also update that regularly with Capgo.
Ich hoffe, ich kann bessere Prüfungen vor der Buildphase für Capgo hinzufügen. bundle upload Voraussetzungen in meine semantic release-Konfiguration einfügen.
Ich habe jetzt eine saubere, einfache und reproduzierbare semantic release Pipeline für zukünftige mobile Apps, die mit Ionic + Angular + Capacitor entwickelt werden.
Autor - Rupert Barrow
Ich habe über 22 Jahre Erfahrung mit Salesforce, als Kunde und Benutzer, als Partner und Integrator, Architekt, Entwickler, Geschäftsanalytiker und Berater. Ich gründete und leitete Altius Services als COO und CTO für 13 Jahre, ein erfolgreicher Salesforce-Partner in Frankreich, bevor ich mich auf eine neue Abenteuer als Salesforce-Solopreneur mit meinem Rapido Cloud Produktangebot
Sie finden mich auf LinkedIn bei https://linkedin.com/in/rbarrow.
Sie können unsere Salesforce-Angebote auf unserer Website ansehen https://www.rapido-companion.app und https://www.rapido.cloud (unter Entwicklung).
Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater
Wenn Sie __CAPGO_KEEP_0__ verwenden How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater um live update Lieferungen zu planen, 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 der Updateverhaltensweise und Update-Typen Für die Implementierungsdetails in den Update-Typen.
