1. Einleitung
Bei Rapido Cloud (www.rapido.cloud), entwickle ich eine mobile Anwendung für Salesforce-Kunden, damit sie ihre eigenen markenorientierten mobilen Anwendungen leicht ohne die schwierigen Schleifen des Salesforce Mobiles SDK oder des Salesforce Mobile Publishers bereitstellen können.
Ich habe diese mobile App auf einem modernen und "standard"-Plattform mit weit verbreiteten Komponenten und Werkzeugen wie Ionic 8, Angular 18, TypeScript, Capacitor und nun Capgo CapacitorUpdater entwickelt. 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, Ionic + Angular-Mobilanwendungen zu rekrutieren und zu pflegen.
Dieser Artikel erklärt meine Konzeption, meine Entscheidungen und meine Implementierung, die zu einem sehr erfolgreichen und unkomplizierten Management aller Bereitstellungen über Capgo Actions führen. Alles wurde während der schönen 14-tägigen kostenlosen Testzeit von __CAPGO_KEEP_1__ CapacitorUpdater entworfen, getestet und dokumentiert. 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.
Capgo CapacitorUpdater hat mich mit seiner Versprechung angezogen, die mobilen App-Bereitstellungen viel einfacher, viel schneller und flexibler zu machen als der Standardprozess für Apple AppStore/Google PlayStore.
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 war zunächst besorgt über die Lernkurve, um dies erfolgreich zu machen, aber ich habe meine App leicht auf Apple TestFlight gebracht. Dann war ich in der Lage, Capgo CapacitorUpdater zu verwenden, um meine Updates viel schneller zu deployen.
Mein erster Anforderung und Testfall war es, meine App für mich selbst zu deployen, um meine App als echte mobile App auf meinem eigenen Telefon zu testen, anstatt in einer mobilen Emulator oder in einem Simulator über die Nexus-Mobilbrowser vorgeschlagen von IIonic zu testen. 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 besser, als die echte App, in echten Bedingungen zu testen !
So Capgo CapacitorUpdater half mir, meine Anwendung auf meinem Mobilgerät live zu aktualisieren, 1 Minute nachdem ich eine neue Funktion oder ein Fix in meiner Quellcode code gespeichert hatte : so erleichternd, und so flexibel, und leicht zu konfigurieren !
3. Mein Branching- und Release-Modell, und wie semantic-release hineinpasst
So jetzt habe ich meine Lieferung an Capgo Server korrekt funktionieren, ich muss dies automatisieren und es in mein CI/CD-Pipeline einfügen.
Dies ist, wie ich mein Branching- und Release-Modell organisiere
Für jede Anwendung, ob mobil, web oder Salesforce :
- Entwicklung erfolgt auf
feature/...Branchenmain, und sie werden inmaindie ist die Referenz für die meisten Entwicklungszweige, außerhalb von Wartung und spezifischen Funktionen für benutzerdefinierte Lieferungen (mehr darüber unten) - Deployments werden ausgelöst aus Releasezweigen welche sein können :
production, Vorklausurrezweige (alpha,beta,nightly, usw.) und auch Kunden- oder Kontextspezifische Zweige für individuelle Lieferungen - Deployments werden durch einen Pull-Request ausgelöst der in einen Bereitstellungs-Zweig eingepflegt wird. Ich verwende keine tag-gesteuerten Bereitstellungen, da semantic-release die Tags und alles andere für mich verwaltet.
Im Grunde handelt es sich um den Gitlab-Flow :
Gitlab-Flow - Quelle https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Ein Seitenhinhinweis, wie semantic-release funktioniert :
In einer Bereitstellungsbranche wird, wenn semantic-release ausgelöst wird, automatisch die neue Versionsnummer auf dieser Branche berechnet, abhängig von der Versionsnummer des vorherigen Tags auf der Branche und den gelieferten Fixes oder Features. Fixes erzeugen eine neue Patchversion, während Features eine neue Minorversion erzeugen. Es wird auch automatisch die Prerelease alpha, beta, usw. in der Versionsnummer.
Semantic release generiert den Changelog aus Ihren Commits, gruppiert Fixes und Features wie in conventional 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-Anfragen und damit verbundenen Probleme mit Kommentaren verknüpfen, die sie mit dem Tag und der Veröffentlichung verbinden. Schließlich wird in dieser Github Veröffentlichung es die erforderlichen Dateien wie Quellcode code, Binärdateien, usw. CHANGELOG.md, usw.
4. Branchen, Releases/Prereleases, Kanäle in semantic release und in Capgo
So, was ich von semantic release für Capgo-Bereitstellungen erreichen möchte.
Ich möchte, dass semantic release die Versionsnummer
Capgo haben ihre eigene Version der "Conventional Commits"-Tool entwickelt und dokumentiert, mit ihrem forkierten Repository standard-version __CAPGO_KEEP_1__ ist die Release 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) Repositories. Sie haben auf ihrem Blog die Versionsnummerierung beschrieben, die von Capgo in ihren Bereitstellungen verwendet wird (https://capgo.app/blog/how-version-work-in-capgo/) . JavaScript-Bundles folgen der 'standard' semver 'Semantic Versioning' (https://semver.org) , die auch (offensichtlich!) folgt semantic-release So ist das großartig, und ist für mich eine Erleichterung, weil ich
CapacitorUpdater semantic-release extensiv.
Ich möchte auch, dass semantic release App-Deployments auf verschiedenen Kanälen generiert.
Wie oben erwähnt, benötige ich, um eine Vorkonfiguration auszuführen, Versionen aus Zweigen wie alpha, beta, nightly z.B. etc., aber auch Kunden-spezifische Versionen auf Zweigen wie production-customer-jones, production-customer-doe, usw.
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 in die 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.1aus. Erfolgreiche Builds auf diesem Zweig werden die Buildnummer um 1.0.0-alpha.2erhöhen, 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 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 in Capgo zu automatisieren, müssen Sie den Capgo CLI-Befehl verwenden. bundle uploadTippen Sie npx @capgo/cli@latest bundle upload --help um die zahlreichen Uploadoptionen zu erhalten. Unter denen verwenden wir die folgenden :
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 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, wie passt sich alles zusammen ?
Mit semantic release erstellte App-Bundle-Versionen mit Github Actions
Semantic release-Automatisierung mit Github Actions
Die Schönheit von semantic release besteht darin, dass die Bereitstellungsautomatisierung, in Form einer Github Action-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.
For jede Mergen auf einer Zweig, die in branches, wird eine semantische Freigabe ausgelöst.
Setze CAPGO_APIKEY in deinem Repositoriums-Secrets.
Aktualisiere deine CAPGO_APPID hier.
Die Verhaltensweise der semantischen Freigabe wird in ihrem .releaserc.json konfiguriert.
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:branchesLegt die Konfiguration der Zweige (name), mapped to the Capgo channel (channelKanal (prerelease) abgebildet werden und wie die Vorkomponentennummer genannt werden wird (branch.prerelease = "development"). Zum Beispiel, wennx.y.z-development.n- , wird die von der semantischen Freigabe generierte Versionsnummer sein:
Deployments zu dem
alphaundalpha-nocapgowerden beide die App auf dem Kanal bereitstellen, aber mit unterschiedlichen Vorklauseln im Versionsnummeralphaoder - werden beide auf den
dev-rupertKanal deployen, aber mit unterschiedlichen Vorklauseln in der Versionsnummerdev-pauldeployen sie auf dendevelopmentchannel on Capgo, all with the samedevelopmentdeployen sie auf den
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-analyzeres prüft in der ersten Stufe der semantischen Veröffentlichung, ob es den richtigen Zugriff auf den Kanal hathttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: standardmäßige semantische Veröffentlichungs-Features - siehe ihre Dokumentation (https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format: )CHANGELOG.md@semantic-release/git: committiere die folgenden Dateien, die durch die Ionic-Build des Anwendungs und durch die Arbeit von semantic release aktualisiert wurden (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android@semantic-release/github: anhängen Sie dasCHANGELOG.mdDatei an die Github-Veröffentlichung als Asset@semantic-release/exec: verwenden Sie 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 Erklärungen erforderlich sind, wie wir die Versionsnummer berechnen und erhöhen möchten, wie wir eine Changelog erstellen, eine Github-Tag oder -Veröffentlichung usw. : alles wird durch semantic release standardmäßig mit minimaler Konfiguration gehandhabt.
Neue Binärdateien mit XCode Cloud erstellen
Integrieren Sie all dies mit XCode Cloud, um neue Versionen der Anwendungsbinärdatei 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.
production) - auf dieser Branch, habe ich XCode Cloud eingerichtet, um nur zu bauen, wenn die
CHANGELOG.mdDer Datei wird aktualisiert. 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.
branch.channelBei jeder Konfiguration des XCode Cloud-Builds auf einem anderen Branch setze ich eine Umgebungsvariable manuell mit dem Wert vonreleaserc.jsonset in
Erstellung von App-Binärdateien auf XCode Cloud mit Capgo Kanälen
Erstellung von App-Binärdateien auf XCode Cloud mit __CAPGO_KEEP_0__ Kanälen
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 :
- Zusammenfassend bin ich sehr zufrieden, dass ich Capgo CapacitorUpdater in meine Standardpipeline für semantic release integrieren konnte, schnell innerhalb der 14-tägigen Testzeit und das Ergebnis ist wie folgt:
- semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
- semantic release deployt __CAPGO_KEEP_0__-Anwendungsdateien automatisch, wobei auch __CAPGO_KEEP_1__-Kanäle verwendet werden.
Dies passt gut in die XCode Cloud-Builds von Anwendungsbinärdateien ein.
I bin mich derzeit in der Entwicklungsphase dieses Apps. Ich werde es schnell den Testern über TestFlight (für iOS) zur Verfügung stellen. Unter Berücksichtigung der Leistung von Capgo, werde ich sicherlich eine kostenlose Version der App im AppStore für Tests bereitstellen, die regelmäßig mit Capgo während der Tests aktualisiert wird. Ich werde dann eine weitere (bezahlte) Version der App im AppStore bereitstellen, unter einer anderen Aufzeichnung, und auch regelmäßig mit Capgo aktualisieren.
I hoffe, ich kann bessere Voraussetzungen für die Vorbereitung von Capgo in meine semantische Release-Konfiguration hinzufügen. bundle upload Für zukünftige mobilen Apps, die mit Ionic + Angular + __CAPGO_KEEP_0__ entwickelt werden, habe ich jetzt eine saubere, einfache und reproduzierbare semantische Release-Pipeline.
I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.
Mit über 22 Jahren Erfahrung bei Salesforce, als Kunde und Nutzer, als Partner und Integrator, Architekt, Entwickler, Geschäftsanalyst und Berater, habe ich Altius Services als COO und CTO für 13 Jahre mitgegründet und geleitet, ein erfolgreiches Salesforce SI-Partner 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 unter .
https://www.rapido-companion.app 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 How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater um Live-Update-Lieferungen zu planen, verbinden Sie es mit Capgo Live Updates für das Produktworkflow in Capgo Live Updates, Übersicht für die Implementierungsdetails in Übersicht, Funktionen zur Implementierungsdetail in Features, Updateverhalten zur Implementierungsdetail in Updateverhalten, und Updatearten zur Implementierungsdetail in Updatearten.
