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.
Warum verwenden Sie Capgo ? Warum verwenden Sie semantic-release ?
Capgo CapacitorUpdater hat mich mit seiner Versprechung angezogen, mobile App-Deployments viel einfacher, viel schneller und flexibler als das Standardverfahren über die Apple AppStore/Google PlayStore zu gestalten. Dies ist meine erste mobile Anwendung, die ich in die Vertriebskanäle bringe, nachdem ich in der Vergangenheit hauptsächlich Webanwendungen entwickelt habe, die auf der Salesforce Experience Cloud basieren.
Ich war eher besorgt über die Lernkurve, um dies 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.
Meine erste Anforderung und Testfälle war es, meine App für mich selbst zu deployen, um meine App als echte mobile App auf meinem eigenen Smartphone zu testen, anstatt in einem mobilen Emulator oder in einem Simulator über die Nexus-Mobilbrowser, die von IIonic empfohlen wird. Das ist, weil 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 nicht sicher, 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 Mobilgerät live zu aktualisieren, 1 Minute nachdem ich eine neue Funktion oder ein Fix in meiner Quelldatei 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 Lieferung an Capgo Server korrekt funktionieren, ich muss dies automatisieren und in mein CI/CD-Pipeline einfügen.
So organisiere ich meine Branchen und Release-Modelle
For every application, whether mobile, web or Salesforce :
- development wird durchgeführt auf
feature/...Branchen abgeleitetmainund werden dann zu einem zusammengefasstenmaineingefügt, das ist die Referenz für die meisten Entwicklungszweige, außerhalb von Wartung und spezifischen Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten) - die Bereitstellung wird ausgelöst aus Releasezweigen die möglicherweise :
production, Vorkomponenten-Zweige (alpha,beta,nightly, usw.) und auch benutzerdefinierte oder kontextabhängige Zweige für benutzerdefinierte Lieferungen - Deployments werden durch einen Pull-Request ausgelöst. Sie werden in eine Bereitstellungszweig integriert. Ich verwende keine tag-gesteuerten Bereitstellungen, 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
Hinweis zur Funktionsweise von semantic-release :
Bei einer Bereitstellungszweig wird semantic-release ausgelöst, es berechnet automatisch die neue Versionsnummer auf dieser Zweig, basierend auf der Versionsnummer des vorherigen Tags auf der Zweig 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, beta, usw. in der Versionsnummer.
Semantic release generiert den Changelog aus Ihren Commits, gruppiert Fixes und Features, wie in konventionellen Commits (siehe https://www.conventionalcommits.org/de/ueber) definiert und in semantic release konfiguriert.
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
So, was ich für Capgo-Deployments von semantic release haben 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 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 auch capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-Plugin-Standard-Version) Repositories haben dies auf ihrem Blog dokumentiert: Die Versionsnummerierung, die von Capgo in ihren Bereitstellungen verwendet wird (https://capgo.app/blog/wie-versionsnummern-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
Wie oben erwähnt, muss ich eine Vorkonfiguration von Branches 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 in die verschiedenen Branch-Builds, die von XCode Cloud verwaltet werden (siehe mehr dazu 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 auf 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 ?
App-Bundle-Versionen, die mit semantischer Veröffentlichung und Github Actions erstellt wurden
Semantische Veröffentlichung mit Github Actions
Die Schönheit der semantischen Veröffentlichung besteht darin, dass die Bereitstellungsautomatisierung, in Form eines Github-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 branches, semantic release will trigger a deployment.
Set CAPGO_APIKEY in Ihrem Repositorys Geheimnissen.\nAktualisieren Sie Ihre CAPGO_APPID hier.
Das Verhalten von semantic release wird in seinem .releaserc.json Konfigurationsdatei.
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 Konfiguration der Branches (name), die dem Capgo-Kanal (channel) und wie die Vorelektroversion-Nummer genannt wird ("prerelease) zugeordnet ist. Zum Beispiel, wennbranch.prerelease = "development", wird die von semantic release generierte Versionsnummerx.y.z-development.n- zur Veröffentlichung auf den
alphaundalpha-nocapgozur Veröffentlichung auf den Entwickler-BranchesalphaKanal, aber mit unterschiedlichen Voreinstellungen in der Versionsnummer - zur Veröffentlichung auf den Entwickler-Branches
dev-rupertordev-paulwerden beide auf dasdevelopmentchannel auf Capgo, alle mit demselbendevelopmentVorabversionsschlü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 des Anwendungs und durch die semantische Veröffentlichung bearbeitet wurden (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android.@semantic-release/github: anhängenCHANGELOG.mdDatei zur Github-Version als Asset@semantic-release/exec: verwenden Sie diese 2 Befehle, um die App-Build vorzubereiten (prepareCmd) und dann effektiv das App-Bundle auf die Capgo-Server zu bauen und zu deployen ("publishCmd)
Sie werden feststellen, dass keine Erklärungen erforderlich sind, wie die Versionsnummer berechnet und inkrementiert werden soll, wie ein Changelog, ein Github-Tag oder Release generiert werden soll usw. : Alles wird durch 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 bin 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 Branch eine Änderung vorgenommen wird (z.B.
production) - auf dieser Branch setze ich XCode Cloud ein, um nur dann zu bauen, wenn die
CHANGELOG.mdDatei aktualisiert wurde. Dies wird nach jeder durch 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 von
branch.channelgesetzt inreleaserc.json(ja, dies ist eine manuelle Duplikation) und dann, wenn ich wollte, könnte ich ein anderes AppStore-Anwendungsprogramm für jeden benutzerdefinierten Kundenanwendungsprogramm bereitstellen, das aus einem benutzerdefinierten Release-Branch bereitgestellt wird, wie oben erwähnt.
Binärcode der App auf XCode Cloud mit Capgo-Kanälen erstellen
7. Conclusion
Zusammenfassend bin ich sehr glücklich, Capgo CapacitorUpdater in meine Standardpipeline für semantische Releases integriert haben zu haben, innerhalb der Verzögerung des 14-Tage-Testzeitraums, und das Ergebnis ist wie folgt :
- Die Versionsnummern der Pakete werden automatisch durch semantische 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 Anwendungsbinären
Nächste Schritte
Ich bin derzeit in der Entwicklungsphase dieses Projekts. Ich werde es 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 bereitstellen, die regelmäßig mit Capgo aktualisiert wird. Dann werde ich eine weitere (bezahlte) Version der App im AppStore bereitstellen, unter einem anderen Account, und auch diese regelmäßig mit Capgo aktualisieren.
I hope to add better pre-build verification of Capgo bundle upload Vorraussetzungen in meine semantische Release-Konfiguration einfügen.
Ich habe jetzt eine saubere, einfache und reproduzierbare Pipeline für semantische Releases für zukünftige mobilen Apps, die mit Ionic + Angular + Capacitor entwickelt werden.
Autor - Rupert Barrow
I habe über 22 Jahre Erfahrung mit Salesforce, als Kunde und Nutzer, als Partner und Integrator, Architekt, Entwickler, Geschäftsanalyst und Berater. Ich gründete und leitete Altius Services als COO und CTO für 13 Jahre, 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 unserer Website ansehen. https://www.rapido-companion.app und https://www.rapido.cloud https://www.rapido.cloud
Weitermachen von Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet
Wenn Sie Capgo verwenden How Rapido Cloud verwalten Sie Semantic Release mit Capgo CapacitorUpdater um live update Lieferung zu planen, verbinden Sie es mit Capgo Live Updates zur Produktworkflow in Capgo Live Updates Übersicht zur Implementierungsdetail in Übersicht Funktionen zur Implementierungsdetail in Funktionen Updateverhalten zur Implementierungsdetail in Updateverhalten und Updatearten zur Implementierungsdetail in Updatearten.
