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 a very successful no-brainer for managing all deployments automatically via Github Actions. All this was designed, tested and documented during the nice 14-day free trial period of Capgo CapacitorUpdater.
2. Warum Capgo verwenden? Warum Semantic Release verwenden?
Capgo CapacitorUpdater hat mich mit seiner Versprechung angezogen, mobile App-Deployments viel einfacher, viel schneller und flexibler als das Standardverfahren über Apple AppStore/Google PlayStore zu gestalten. Dies ist meine erste mobile Anwendung, die ich in die Vertriebskanäle bringe, nachdem ich mich in der Vergangenheit auf Webanwendungen konzentriert habe, die üblicherweise auf der Salesforce Experience Cloud entwickelt wurden.
Ich war eher von der Lernkurve abgeschreckt, um dieses Projekt erfolgreich zu machen, aber ich konnte meine App leicht auf Apple TestFlight bringen. Dann war ich in der Lage, Capgo CapacitorUpdater zu verwenden, um meine Updates viel schneller zu deployen.
Mein erster Anspruch und Testfall war es, meine App für mich selbst zu deployen, um meine App als echte mobile App auf meinem eigenen Smartphone zu testen, anstatt sie in einem mobilen Emulator oder in einem Simulator über die Nexus-Mobilbrowser zu testen, die von IIonic empfohlen wird. Das liegt daran, dass meine App native Funktionen wie Geolocation oder den Zugriff auf die Foto-Galerie und die Kamera verwendet. Ohne die Erfahrung der Vergangenheit, eine Capacitor mobile App zu testen, war ich unsicher, ob alles richtig funktionieren würde : nichts ist besser, als die echte App in realen Bedingungen zu testen !
So half mir Capgo CapacitorUpdater, meine Anwendung auf meinem mobilen Gerät live zu aktualisieren, 1 Minute nachdem ich eine neue Funktion oder ein Fix in meiner Quellcode-code gespeichert hatte : so erleichternd, so flexibel und einfach zu konfigurieren !
3. Mein Branching- und Release-Modell und wie semantic-release hineinpasst
So habe ich jetzt meine Auslieferung an Capgo Server korrekt eingerichtet, ich muss dies automatisieren und in meine CI/CD-Pipeline einfügen.
So organisiere ich meine Branching- und Release-Modell
Für jede Anwendung, unabhängig davon, ob es sich um eine mobile, Web- oder Salesforce-Anwendung handelt :
- erfolgt die Entwicklung auf
feature/...Branchen abmainund sie werden inmaineingefügt, das ist die Referenz für die meisten Entwicklungszweige, außerhalb von Wartung und spezifischen Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten) - sind die Bereitstellungen ausgelöst von Releasezweigen die möglicherweise :
production, Vorkomponenten-Zweige (alpha,beta,nightly, usw.) und auch kunden- oder kontextspezifische Zweige für benutzerdefinierte Lieferungen - Deployments werden durch einen Pull-Request ausgelöst. Ich verwende Deployments, die durch einen Pull-Request ausgelöst werden, weil semantic release die Tags und alles andere für mich verwaltet.
Im Grunde ist das der Gitlab Flow :
Gitlab Flow - Quelle https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Ein Seitenhinhinweis, wie semantic-release funktioniert :
In einer Deployment-Branch, wenn semantic-release ausgelöst wird, berechnet es automatisch die neue Versionsnummer auf dieser Branch, basierend auf der Versionsnummer des vorherigen Tags auf der Branch und den gelieferten Fixes oder Features. Fixes erzeugen eine neue Patchversion, während Features eine neue Minorversion erzeugen. Es beinhaltet auch automatisch die Prerelease alpha, betaetc. in der Versionsnummer.
Semantic release generiert den Changelog aus Ihren Commits, gruppiert Fixes und Features, wie in conventinal Commits definiert (siehe https://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.md, usw.
4. Zweige, Releases/Prereleases, Kanäle in semantic release und in Capgo
Also, was ich von semantic release für Capgo-Deployments erwarten möchte, ist Folgendes.
Ich möchte, dass semantic release die Versionsnummer generiert.
Capgo haben ihre eigene Version der "Conventional Commits"-Methode entwickelt und dokumentiert. standard-version tool, mit ihrem forkierten Repository standard-version (https://github.com/Cap-go/standard-version), und ihre eigenen capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) sowie capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. They have documented on their blog the version scheme used by Capgo in their deployemnts (https://capgo.app/blog/how-version-work-in-capgo/). JavaScript-Bundles folgen der "standard" semver "Semantic Versioning" (https://semver.org) die auch (offensichtlich !) semantic-release So ist das großartig und ist für mich eine Erleichterung, da ich sie sehr intensiv verwende.
Ich möchte auch, dass semantic release App-Bereitstellungen auf verschiedenen Kanälen generiert. semantic-release Wie oben erwähnt, benötige ich, um Voreinstellungen zu bereitstellen, die aus Zweigen wie
etc. stammen, aber auch Kunden-spezifische Versionen aus Zweigen wie
etc. alpha, beta, nightly etc., but also customer-specific versions on branches such as 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 zusammen zu machen. Diese passen auch zu den verschiedenen Branch-Builds, die von XCode Cloud verwaltet werden (siehe mehr darüber unten).
Semver-Versionen, die von semantic release auf Prereleases generiert werden, sehen wie folgt aus 1.0.0-alpha.1. Erfolgreiche Builds auf diesem Branch erhöhen die Buildnummer um 1.0.0-alpha.2, usw. 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 Prerelease 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 über Capgo zu automatisieren, müssen Sie den Capgo CLI-Befehl verwenden bundle upload. Tippen Sie 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- KANAL ist der Capgo-Kanal, auf den wir deployen möchten (z.B.
alpha) - VERSION wird von 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 semantische Veröffentlichung + Capgo CapacitorUpdate-Einrichtung
Schließlich passt sich alles zusammen ?
Mit semantischer Veröffentlichung erstellte App-Bundle-Versionen mit Github Actions
Semantische Veröffentlichungsautomatisierung mit Github Actions
Die Schönheit der semantischen Veröffentlichung besteht darin, dass die Bereitstellungsautomatisierung, in Form eines Github Actions-Workflows, 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 die semantische Veröffentlichung auf.
Für jeden Merge auf einer in branchessemantic release wird eine Bereitstellung ausgelöst.
Set CAPGO_APIKEY im Geheimnis deiner Repositorys.
Aktualisiere deine CAPGO_APPID hier.
Die semantische Veröffentlichung wird durch ihre .releaserc.json Einstellungsdatei.
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:branchesdie Einstellungen der Zweige (name), die dem Capgo-Kanal (channel) und der Art und Weise zugewiesen sind, wie die Vorkonfigurationsversionnummer genannt wird (prerelease). Zum Beispiel, wennbranch.prerelease = "development"die von semantic release generierte Versionsnummerx.y.z-development.n- Zu den
alphaundalpha-nocapgoZweige werden beide auf denalphaKanal deployen, aber mit unterschiedlichen Vorkonfigurationsnamen in der Versionsnummer - Zu den Entwicklerzweigen
dev-rupertoderdev-paulwerden beide auf den __CAPGO_KEEP_0__-Kanal deployen, alle mit dem gleichen Prärelase-Schlüssel in der VersionsnummerdevelopmentKanal auf Capgo, alle mit dem gleichen Prärelase-Schlüssel in der VersionsnummerdevelopmentPrärelase-Schlüssel 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 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/git: Füge die folgenden Dateien hinzu, die durch die Ionic-Build der Anwendung und durch die semantische Veröffentlichung bearbeitet wurden (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj: Füge die Datei als@semantic-release/githubAsset zur __CAPGO_KEEP_0__-Veröffentlichung anCHANGELOG.mdfile to the Github release as an asset@semantic-release/exec: Verwenden Sie diese 2 Befehle, um die App-Build vorzubereiten (prepareCmd) und dann effektiv die App-Bundle auf den Capgo-Servern (publishCmd)
Sie werden feststellen, dass keine Zeit damit verbracht wird, zu erklären, wie die Versionsnummer berechnet und inkrementiert werden soll, wie ein Changelog, ein Github-Tag oder Release generiert werden soll usw. : Alles wird von semantic release standardmäßig mit minimaler Konfiguration gehandhabt.
Erstellung neuer Binärdateien mit XCode Cloud
Die Integration aller dieser Funktionen mit XCode Cloud zur Erstellung neuer Versionen der Anwendungsbinärdatei ist einfach (ich habe noch nicht auf Google Play deployt, aber die Build sollte ähnlich sein) :
- Ich habe einen XCode Cloud-Prozess eingerichtet, der gebaut wird, wenn auf der von mir gewünschten Zweig eine Änderung vorgenommen wird (z.B.
production) - auf diesem Zweig habe ich XCode Cloud eingerichtet, damit es nur gebaut, wenn die
CHANGELOG.mdDatei aktualisiert wird. Dies wird nach jeder von semantic release generierten Version aktualisiert. - Ich kann Builds auf verschiedenen Zweigen auslösen, um die Bereitstellung für verschiedene Kanäle zu simulieren. In jeder Konfiguration von XCode Cloud- Build auf einem anderen Zweig setze ich eine Umgebungsvariable manuell mit dem Wert von
branch.channelgesetzt inreleaserc.json(ja, dies ist eine manuelle Duplikation) und dann könnte ich, wenn ich wollte, ein anderes AppStore-Anwendungsprogramm für jeden benutzerdefinierten Kundenanwendungsprogramm bereitstellen, das aus einem benutzerdefinierten Release-Zweig bereitgestellt wird, wie oben erwähnt.
Binärcode für Apps auf XCode Cloud mit Capgo-Kanälen erstellen
7. Fazit
Zusammenfassend bin ich sehr glücklich, Capgo CapacitorUpdater in meine Standardpipeline für semantische Releases integriert haben zu haben, schnell innerhalb der Verzugsfrist von 14 Tagen, und das Ergebnis ist wie folgt:
- Die Versionsnummern der Pakete werden automatisch von semantischen Releases generiert und sind mit den Capgo-Servern kompatibel
- semantische Releases deployen Capgo-Anwendungs-Pakete automatisch, wobei auch Capgo-Kanäle verwendet werden
- Dies passt gut zu den XCode-Cloud-Builds von Binärcode für Anwendungen
Zukünftige Schritte
Ich bin derzeit in der Entwicklungsphase dieses Apps. Ich werde sie schnell über TestFlight (für iOS) an Tester verteilen. Angesichts der Leistungsfähigkeit von Capgo werde ich sicherlich eine kostenlose Version der App im AppStore für Tests bereitstellen, die regelmäßig mit Capgo aktualisiert wird. Dann werde ich eine weitere (bezahlte) Version der App im AppStore bereitstellen, unter einer anderen Aufzeichnung, und auch diese regelmäßig mit Capgo aktualisieren.
I hope to add better pre-build verification of Capgo bundle upload Jetzt habe ich eine saubere, einfache und reproduzierbare Pipeline für semantische Releases für zukünftige mobilen Apps, die mit Ionic + Angular + __CAPGO_KEEP_0__ entwickelt werden.
I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.
Zukünftige Schritte
I habe über 22 Jahre Erfahrung mit Salesforce, als Kunde und Nutzer, als Partner und Integrator, Architekt, Entwickler, Geschäftsanalyst und Berater. Ich habe Altius Services als COO und CTO mitgegründet und 13 Jahre lang geleitet, ein erfolgreicher Salesforce SI-Partner in Frankreich, bevor ich mich auf eine neue Abenteuer als Salesforce-Solopreneur mit meinem Rapido Cloud Produktangebot
Sie finden mich auf LinkedIn unter https://linkedin.com/in/rbarrow.
Sie können unsere Salesforce-Angebote auf https://www.rapido-companion.app und https://www.rapido.cloud (in Entwicklung).
Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater
Wenn Sie Capgo verwenden How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater um lebendige Aktualisierungen zu planen, verbinden Sie es mit Capgo Live Updates for the product workflow in Capgo Live Updates, Übersicht zur Implementierungsdetail in Übersicht Funktionen zur Implementierungsdetail in Funktionen Aktualisierungsverhalten zur Implementierungsdetail in Aktualisierungsverhalten Aktualisierungstypen zur Implementierungsdetail in Aktualisierungstypen
