Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet
1. EinführungBei 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 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 keine Salesforce-Plattform-Spezifika wie Lightning Web Components verwalten möchten; und es ist einfacher und günstiger für mich, Entwickler und Maintainer von Ionic + Angular-Mobilanwendungen zu rekrutieren.
Dieses Artikel erklärt meine Konzeption, meine Entscheidungen und die Implementierung, die zu einem sehr erfolgreichen und unkomplizierten Management aller Bereitstellungen über Capgo führen. 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, mobile App-Bereitstellungen viel einfacher, viel schneller und flexibler zu machen als das Standardverfahren über 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.
Mir war die Lernkurve, um dies erfolgreich zu machen, ein bisschen bange, 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.
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 helped me update my application on my mobile, live, 1 minute after saving a new feature or fix in my source code : so relieving, and so flexible, and easy to set up !
3. Mein Branching- und Release-Modell, und wie semantic-release hineinpasst
So jetzt habe ich meine Lieferung an Capgo-Servern korrekt funktionieren, ich muss dies automatisieren und in mein CI/CD-Pipeline einfügen.
Dies ist, wie ich mein Branching- und Release-Modell organisiere
Für jede Anwendung, sei es mobile, Web oder Salesforce :
- Entwicklung findet statt auf
feature/...Zweigen abmain, und sie werden inmainmerge - , welches die Referenz für die meisten Entwicklungszweige ist, außer für Wartung und spezifische Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten). aus Releasezweigen die möglicherweise :
production, Vorabversionen (alpha,beta,nightly, usw.) und auch Kunden- oder Kontextspezifische Zweige für benutzerdefinierte Lieferungen - Deployments werden durch einen Pull-Request ausgelöst der in einen Deployment-Zweig eingepflegt wird. Ich verwende keine tag-gesteuerten Deployments, 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
Eine Nebenbemerkung zu wie semantic-release funktioniert :
In einem Deployment-Zweig wird, wenn semantic-release ausgelöst wird, automatisch die neue Versionsnummer auf diesem Zweig berechnet, je nach Versionsnummer des vorherigen Tags auf dem Zweig und den gelieferten Fixes oder Features. Fixes erzeugen eine neue Patchversion, während Features eine neue Minorversion erzeugen. Es wird auch automatisch die Vorabversion einbezogen alpha, betausw. in der Versionsnummer.
Semantic release generiert die Änderungsliste aus Ihren Commits, gruppiert Fehler und Funktionen 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 verknüpfen, die auf die Versionsnummer und die Veröffentlichung verweisen. Schließlich wird in dieser Github-Veröffentlichung es auch Dateien wie Quellcode (code), Binärdateien, wenn nötig, CHANGELOG.md, usw.
4. Zweige, Veröffentlichungen/Vorabveröffentlichungen, Kanäle in semantic release und in Capgo
Also, was ich von semantic release für Capgo-Deployments möchte, ist Folgendes.
Ich möchte, dass semantic release die Versionsnummer
Capgo haben ihre eigene Version der „Conventional Commits“- standard-version Tool entwickelt und dokumentiert, 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) 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!) semantic-release So ist das großartig, und ist für mich eine Erleichterung, weil ich
extensiv verwende. semantic-release extensively.
I möchte auch, dass semantic release App-Deployments auf verschiedenen Kanälen generiert
Wie oben erwähnt, benötige ich, um eine Vorkonfiguration von Branches wie alpha, beta, nightly etc., aber auch Kunden-spezifische Versionen auf Branches 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 in die verschiedenen Branch-Builder, die von XCode Cloud verwaltet werden (siehe mehr darüber unten).
Semver-Versionen, die von semantic release auf Vorkonfigurationen generiert werden, sehen wie 1.0.0-alpha.1Successive Builds auf diesem Branch werden die Buildnummer um eins erhöhen auf 1.0.0-alpha.2, etc. Auch wenn dies nicht explizit dokumentiert ist, werden diese Versionen 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 automatisierte Bereitstellung Ihrer App-Bundles auf Capgo zu automatisieren, müssen Sie den Capgo CLI-Befehl 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- 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 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 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 semantic release auf.
Für jeden Merge auf einer in branches, semantic release wird eine Bereitstellung auslösen.
Set CAPGO_APIKEY im Geheimnis deiner Repositorys.
Aktualisiere deine CAPGO_APPID Siehe hier.
Die Funktionsweise von semantic release wird in ihrem .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:branchessetzt die Konfiguration der Branches (namezu dem Capgo Kanal (channel) und wie die Vorkonfigurationsversionnummer genannt werden wird (prerelease). Zum Beispiel, wennbranch.prerelease = "development", wird die von semantic release generierte Versionsnummer seinx.y.z-development.n- Bereitstellungen an den
alphaundalpha-nocapgoBranches werden beide die App auf dasalphaKanal, aber mit unterschiedlichen Vorklauselnamen in der Versionsnummer - Deployments auf die Entwicklerzweige
dev-rupertoderdev-paulKanal auf __CAPGO_KEEP_0__, alle mit dem gleichendevelopmentchannel on Capgo, all with the samedevelopment: In der ersten Phase der semantischen Veröffentlichung überprüft es, ob es den richtigen Zugriff auf __CAPGO_KEEP_0__ hat. Ich hoffe, ich kann eine Authentifizierungsprüfung für den __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ hier später hinzufügen
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-analyzerhttps://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formathttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: Commite die folgenden Dateien, die durch die Ionic-Build der Anwendung und durch die semantische Veröffentlichungsarbeit aktualisiert wurden (CHANGELOG.md@semantic-release/gitDeployments auf die Entwicklerzweigepackage.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android)@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 die Versionsnummer berechnet und inkrementiert werden soll, wie ein Changelog generiert, ein Github-Tag oder -Release erstellt werden soll usw. : Alles wird von semantic release standardmäßig mit minimaler Konfiguration gehandhabt.
Mit XCode Cloud neue Binärdateien erstellen
Die Integration aller dieser Dinge mit XCode Cloud zur Erstellung neuer Versionen der Anwendungsbinärdatei ist einfach (Ich deploye 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) - Ich habe auf dieser Branch XCode Cloud eingerichtet, damit es nur gebaut, wenn die
CHANGELOG.mdDatei aktualisiert wird. Dies wird nach jeder von semantic release generierten Version aktualisiert. - I kann Builds auf verschiedenen Branches auslösen, um die Bereitstellung für verschiedene Kanäle zu simulieren. In jeder Konfiguration des XCode Cloud-Baus auf einem anderen Zweig setze ich eine Umgebungsvariable manuell mit dem Wert von
branch.channelsetze inreleaserc.json(ja, das 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.
Erstellung von App-Binärdateien auf XCode Cloud mit Capgo-Kanälen
7. Fazit
Insgesamt 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 Versionsnummern der Pakete werden automatisch durch Semantik-Release generiert und sind mit den Capgo-Servern kompatibel
- Semantik-Release deployt Capgo-Anwendungsdateien automatisch, macht auch Gebrauch von Capgo-Kanälen
- Das passt gut in die XCode Cloud-Baumethoden für Anwendungsbinärdateien
Zukünftige Schritte
Ich bin derzeit in der Entwicklungphase dieses Apps. Ich werde es schnell den Testern über TestFlight (für iOS) zur Verfügung stellen. Unter Berücksichtigung der Capgo-Kraft werde ich sicherlich eine kostenlose Version der App auf dem AppStore bereitstellen, um sie zu testen, die regelmäßig mit Capgo aktualisiert wird. Dann werde ich eine weitere (bezahlte) Version der App auf dem AppStore bereitstellen, unter einem anderen Account, und auch regelmäßig mit Capgo aktualisieren.
I hoffe, ich kann bessere Prüfungen vor der Capgo-Erstellung in meine semantische Release-Konfiguration einfügen. bundle upload Voraussetzungen in meine semantische Release-Konfiguration einzufügen.
Für zukünftige mobile Apps, die mit Ionic + Angular + Capacitor entwickelt werden, habe ich jetzt eine saubere, einfache und reproduzierbare semantische Release-Pipeline.
Verfasser - Rupert Barrow
Mit über 22 Jahren Erfahrung bei Salesforce, als Kunde und Benutzer, 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 erfolgreicher Salesforce-Partner für SI 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 bei 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 How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater um die Lieferung von Live-Updates zu planen, verbinden Sie es mit Capgo Live Updates for the product workflow in Capgo Live Updates, Übersicht zur Implementierungsdetail in Übersicht, Features zur Implementierungsdetail in Features, Updateverhalten zur Implementierungsdetail in Updateverhalten, und Updatearten zur Implementierungsdetail in Updatearten.
