Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet
1. EinführungBei Rapido Cloud (www.rapido.cloud) entwickle ich eine mobile Anwendung für Salesforce-Kunden, um ihre eigenen markierten mobilen Anwendungen ohne die schwierigen Schleifen der Salesforce Mobile __CAPGO_KEEP_0__ oder der Salesforce Mobile Publisher zu deployen.2. SDK CapacitorUpdater Konfiguration
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.
Dieser Artikel erklärt meine Konzeption, meine Entscheidungen und die Implementierung, die zu einem sehr erfolgreichen und einfacheren Weg führen, alle Bereitstellungen automatisch über Capgo Actions durchzufü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, die mobilen 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.
Ich war eher von der Lernkurve abgeschreckt, 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.
My erste Anforderung und Testfall war, mein App als echte mobile App auf meinem eigenen Handy zu deployen, anstatt sie in einem mobilen Emulator oder in einem Simulator über den Nexus-Mobilbrowser von IIonic zu testen. Das war nötig, weil meine App native Funktionen wie Geolocation oder den Zugriff auf die Foto-Galerie und die Kamera verwendet. Ohne Erfahrung mit der Testung einer Capacitor-mobilen App war ich mir nicht sicher, ob alles richtig funktionieren würde : nichts ist besser als die Testung der echten App in realen Bedingungen !
Capgo CapacitorUpdater half mir, meine App auf meinem Handy live zu aktualisieren, 1 Minute nachdem ich eine neue Funktion oder ein Fix in meiner Quellcode-code gespeichert hatte : so erleichternd, flexibel und einfach zu konfigurieren !
3. Mein Branching- und Release-Modell und wie semantic-release darin passt
So jetzt habe ich meine Lieferung an Capgo-Server korrekt laufen, 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/...Branchen abmain, und sie werden inmaindie 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 die möglicherweise :
production, Vorkabelzweige (alpha,beta,nightly, usw.) und auch kundenspezifische oder kontextspezifische Zweige für benutzerdefinierte Lieferungen - Die Bereitstellungen werden durch einen Pull-Request ausgelöst der in einen Bereitstellungs-Zweig eingefügt 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
Eine Randbemerkung zu der Funktionsweise von semantic-release :
In einem Bereitstellungs-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 der Vorkabel-Text hinzugefügt alpha, betausw. in der Versionsnummer.
Semantic release generiert die Änderungsliste 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-Anforderungen und damit verbundenen Issues mit Kommentaren verknüpfen, die auf die Tag und Release verweisen. Schließlich wird in dieser Github-Version auch Dateien wie Quellcode (code), Binärdateien, wenn nötig, CHANGELOG.mdusw.
4. Zweige, Releases/Vorabversionen, Kanäle in semantic release und in Capgo
So, was ich von Capgo-Deployments erwarten möchte, ist Folgendes.
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 https://__CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (https://github.com/Cap-go/standard-versionund 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 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) was auch (offensichtlich!) semantic-release So ist das großartig, und das ist für mich eine Erleichterung, weil ich sie
extensiv verwende 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 Vorkonfigurationsversion 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 in die verschiedenen Zweig-Builds, die von XCode Cloud verwaltet werden (siehe mehr darüber unten).
Semver-Versionen, die von semantic release auf Vorkonfigurationsversionen generiert werden, sehen wie 1.0.0-alpha.1Successive Builds auf diesem Zweig werden die Buildnummer um eins erhöhen 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 Vorkonfigurationen verwenden, um Versionen meiner App mit Capgo-Kanälen zu generieren.
5. Wie kann ich Capgo verwenden, um meine Anwendung zu veröffentlichen?
To automate deployment of your app bundles to Capgo, you need to use the Capgo CLI command bundle upload. Typen 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 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 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 semantic release auf.
Für jeden Merge auf einer in der Liste branches, semantic release wird eine Bereitstellung auslösen.
Einstellungen CAPGO_APIKEY in den Geheimnissen Ihres Repositories.
Aktualisieren Sie Ihre CAPGO_APPID Zurück.
Die Funktionsweise des semantischen Releases 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), mapped to the Capgo channel (channel). Zum Beispiel, wennprerelease, wird die von semantischem Release generierte Versionsnummer seinbranch.prerelease = "development"Zu den Bereitstellungen auf dasx.y.z-development.n- und
alphaundalpha-nocapgoWird in beiden Branches auf denalphaKanal, aber mit unterschiedlichen Vorklauselnamen in der Versionsnummer - Deployments auf die Entwickler-Branches
dev-rupertoderdev-paulwird in beiden auf dendevelopmentKanal auf Capgo, alle mit derselbendevelopmentVorklauselwort 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: Standard-Semantik-Veröffentlichungs-Stuff - 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: Commite die folgenden Dateien, die durch die Ionic-Build des Anwendungs und durch die semantische Veröffentlichungsarbeit aktualisiert wurden (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android)@semantic-release/github: füge demCHANGELOG.mdfile to the Github release as an asset@semantic-release/exec: verwende diese 2 Befehle, um die App-Build vorzubereiten (prepareCmd) and then to effectively build deploy the app bundle to the Capgo servers (publishCmd)
You will notice that their is no fiddling around with explaining how we want the version number to be calculated and incremented, how we need to generate a changelog, a Github tag or release, etc. : everything is handled by default by semantic release, with minimal configuration.
Sie werden feststellen, dass keine Zeit damit verbracht wird, wie wir die Versionsnummer berechnen und erhöhen möchten, wie wir eine Changelog generieren müssen, einen
Tag oder Release, usw. : Alles wird durch die semantische Release standardmäßig gehandhabt, mit minimaler Konfiguration.
- Erstellung neuer Binärdateien mit XCode Cloud
production) - Die Integration aller dieser Dinge mit XCode Cloud zur Erstellung neuer Versionen der Anwendungsbinärdatei ist einfach (Ich baue noch nicht auf Google Play, aber die Build sollte ähnlich sein) :
CHANGELOG.mdIch habe einen XCode Cloud-Prozess eingerichtet, der gebaut, wenn es eine Änderung auf der von mir gewünschten Branch gibt (z.B.) - Ich kann Builds auf verschiedenen Branches auslösen, um die Bereitstellung für verschiedene Kanäle zu simulieren.
branch.channelIn jeder Konfiguration des XCode Cloud-Baus auf einem anderen Zweig 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 glücklich, dass ich Capgo CapacitorUpdater in meine Standard-Semantik-Release-Pipeline integrieren konnte, schnell innerhalb der Verzögerung der 14-Tage-Testzeit und das Ergebnis ist wie folgt:
- semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
- Semantik-Release deployt die __CAPGO_KEEP_0__-Anwendungsdateien automatisch, wobei auch __CAPGO_KEEP_1__-Kanäle verwendet werden.
Dies passt gut in die XCode Cloud-Baumethodik für Anwendungsbinärdateien.
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.
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 einfügen.
Für zukünftige mobilen 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 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 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 unter https://linkedin.com/in/rbarrow.
Sie können unsere Salesforce-Angebote unter https://www.rapido-companion.app und https://www.rapido.cloud (in Entwicklung).
Fortsetzung von Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet.
Wenn Sie __CAPGO_KEEP_0__ CapacitorUpdater verwenden. Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet. um Live-Updates zu planen, verbinden Sie es mit Capgo Live-Updates zur Produktworkflow 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.
