1. Einleitung
Bei Rapido Cloud (www.rapido.cloud), entwickle ich eine mobile Anwendung für Salesforce-Kunden, damit sie ihre eigenen brandgeladenen mobilen Anwendungen leicht bereitstellen können, ohne durch die schwierigen Schleifen des Salesforce Mobile __CAPGO_KEEP_0__ oder des Salesforce Mobile Publisher gehen zu müssen.2. ), 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 jetzt 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, Ionic + Angular-Mobilanwendungen zu entwickeln und zu warten.
Dieser Artikel erklärt meine Designentscheidungen, meine Auswahl und die Implementierung, die zu Capgo führen. semantic-release Ein sehr erfolgreicher "Keine-Brötchen"-Ansatz für die automatische Verwaltung aller Bereitstellungen über Github Actions. Alles wurde während der schönen 14-tägigen kostenlosen Testzeit von Capgo CapacitorUpdater entworfen, getestet und dokumentiert.
2. Warum Capgo verwenden? Warum semantic-release verwenden?
Capgo CapacitorUpdater hat mich mit seiner Versprechung angezogen, die mobile App-Bereitstellung viel einfacher, viel schneller und flexibler zu machen als das Standardverfahren über Apple AppStore/Google PlayStore.
Dies ist meine erste mobile Anwendung, die ich in die Läden bringe, da ich in der Vergangenheit auf Webanwendungen konzentriert war, die normalerweise auf der Salesforce Experience Cloud entwickelt wurden. 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 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 !
Der Capgo CapacitorUpdater half mir, meine Anwendung auf meinem Handy live zu aktualisieren, 1 Minute nach dem Speichern einer neuen Funktion oder eines Fixes in meiner Quellcode-code : so erleichternd, und so flexibel, und einfach zu konfigurieren !
3. Meine Branch- und Release-Modell, und wie semantic-release darin passt
So jetzt habe ich meine Lieferung an Capgo Server korrekt funktionieren, ich muss dies automatisieren und in mein CI/CD-Pipeline einfügen.
Dies ist, wie ich mein Branch- und Release-Modell organisiere
Für jede Anwendung, sei es mobile, Web oder Salesforce :
- entwickelt sich abzweigt von
feature/..., und sie werden inmainwelche die Referenz für die meisten Entwicklungszweige ist, außerhalb von Wartung und spezifischen Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten)mainwerden die Bereitstellungen ausgelöst - deployments are triggered aus Releasezweigen welche sein können :
production, Vorabversionen (alpha,beta,nightly, usw.) und auch Kunden- oder Kontextspezifische Zweige für individuelle Lieferungen - Deployments werden durch einen Pull-Request ausgelöst da ein Pull-Request in einen Deployment-Zweig eingefügt wird. Ich verwende keine tag-gesteuerten Deployments, da 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
Etwas zur Funktionsweise von semantic-release :
In einem Deployment-Zweig, wenn semantic-release ausgelöst wird, wird es automatisch die neue Versionsnummer auf diesem Zweig berechnen, abhängig von der Versionsnummer der vorherigen Tag auf dem Zweig und den gelieferten Fixes oder Features. Fixes werden eine neue Patchversion erstellen, während Features eine neue Minorversion erstellen. Es berechnet auch automatisch die Prerelease alpha, beta, usw. in der Versionsnummer.
Semantic release generiert die Änderungsliste aus Ihren Commits, gruppiert Fixes und Features wie in conventioenllen Commits (siehe https://www.conventionalcommits.org/en/about) und konfiguriert in semantic release.
Es wird auch alle Ihre Git-Branches (Github, in meinem Fall) mit Merged Pull Requests und zugehörigen Issues mit Kommentaren verlinken, die auf die Tag und Release verweisen. Schließlich wird in dieser Github-Version es zusätzliche Assets wie Quellcode (code), Binärdateien, wenn nötig, CHANGELOG.md, usw.
4. Zweige, Releases/Prärelases, 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 generiert.
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 (4. Branches, Releases/Prärelases, Kanäle in semantic release und in githubund ihre eigenen capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionsowie capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionRepos. Sie haben auf ihrem Blog die Versionsnummerierung beschrieben, die von Capgo in ihren Bereitstellungen verwendet wird (https://capgo.app/blog/wie-versionen-in-capgo-funktionieren/) JavaScript-Bundles folgen dem "standard"-semver-"Semantic Versioning" (https://semver.org) welches auch (offensichtlich !) semantic-release Daher ist das großartig und ist für mich eine Erleichterung, weil ich es
extensiv verwende. semantic-release extensively
Ich möchte auch, dass semantic release App-Deployments auf verschiedenen Kanälen generiert
Wie oben erwähnt, benötige ich, um eine Vorkonfiguration aus 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 ist, was semantic release auch 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.1Nacheinander werden auf diesem Zweig die Buildnummer um 1.0.0-alpha.2, etc. Obwohl dies nicht explizit dokumentiert ist, werden diese Versionsnummern von Capgo unterstützt, was für mich großartige Nachrichten 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 auf Capgo zu automatisieren, müssen Sie das Capgo CLI-Kommando verwenden bundle uploadTyp 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, wie passt sich alles zusammen?
Mit semantic release und Github Actions erstellte App-Bundle-Versionen
Semantic release-Automatisierung mit Github Actions
Die Schönheit von semantic release besteht darin, dass die Bereitstellung-Automatisierung in Form einer Github Actions-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.
Für jeden Merge auf einer in der Liste aufgeführten Zweig branchessemantic release wird einen Bereitstellungsprozess auslösen.
Einstellungen CAPGO_APIKEY in deinen Repository-Secrets.
Aktualisieren Sie CAPGO_APPID hier.
Die Verhaltensweise von semantic release wird in seinem .releaserc.json Konfigurationsdatei festgelegt.
Hier sind meine Einstellungen, erklärt unten :
// .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:branchesfestlegt die Konfiguration der Branches (name), die auf den Capgo-Kanal (channel) und die Bezeichnung der Vorversion des Versionsnummern (prerelease) abgestimmt sind. Zum Beispiel, wennbranch.prerelease = "development", wird die Versionsnummer, die von semantic release generiert wird,x.y.z-development.n- Bereitstellungen an das
alphaundalpha-nocapgoZweige werden beide die App auf dasalphaKanal, aber mit unterschiedlichen Vorkonfigurationsnamen in der Versionsnummer - Zu den Entwicklerzweigen
dev-rupertoderdev-paulwerden beide auf dasdevelopmentKanal auf Capgo, alles mit derselbendevelopmentVorkonfigurations-Schlüsselwort 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ühre die folgenden Dateien, die durch die Ionic-Build der Anwendung und durch die semantische Veröffentlichungsarbeit aktualisiert wurden, ein (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android, noch nicht)@semantic-release/github: füge dem __CAPGO_KEEP_0__-Release das Datei als Asset hinzuCHANGELOG.mdfile to the Github release as an asset@semantic-release/exec) und dann effektiv die App-Bundle auf den __CAPGO_KEEP_0__-Servern zu deployen (prepareCmdSie werden feststellen, dass es keine Umstände gibt, wie wir die Versionsnummer berechnen und erhöhen möchten, wie wir eine Changelog generieren, einen Capgo-Tag oder Release erstellen müssen, usw. : Alles wird von semantic release standardmäßig gehandhabt, mit minimaler Konfiguration.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.
Die Integration aller dieser Funktionen mit XCode Cloud zur Erstellung neuer Versionen des Anwendungsbinärs ist einfach (Ich baue noch nicht auf Google Play, aber die Build-Operation 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.
- auf dieser Branch, habe ich XCode Cloud eingerichtet, nur zu bauen, wenn die
production) - Datei aktualisiert wird. Diese wird nach jeder von semantic release generierten Version aktualisiert.
CHANGELOG.mdI habe auf dieser Branch, habe ich XCode Cloud eingerichtet, nur zu bauen, wenn die __CAPGO_KEEP_0__-Datei aktualisiert wird. - Ich kann Builds auf verschiedenen Branches auslösen, um die Bereitstellung für verschiedene Kanäle zu simulieren. In jeder Konfiguration des XCode Cloud-Builds 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 jeden benutzerspezifischen Kundenanwendungsprogramm bereitstellen, das von einem benutzerspezifischen 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 zufrieden, 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 :
- Die Versionsnummern von Bundeln 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-Builds von Anwendungsbinärdateien
Nächste Schritte
Ich bin derzeit in der Entwicklungsphase dieses Apps. Ich werde sie schnell den Testern über TestFlight (für iOS) zur Verfügung stellen. Unter Berücksichtigung der Macht von Capgo, werde ich sicherlich eine kostenlose Version der App auf dem AppStore für Tests bereitstellen, die regelmäßig mit Capgo aktualisiert wird. Ich werde dann ein anderes (bezahltes) Anwendungsprogramm auf dem AppStore bereitstellen, unter einem anderen Account, und auch regelmäßig mit Capgo aktualisieren.
Ich hoffe, ich kann bessere Vorberechnungen vor der Capgo in meiner semantic release-Konfiguration hinzufügen. bundle upload Ich habe jetzt eine saubere, einfache und reproduzierbare semantic release Pipeline für zukünftige mobile 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.
Ich 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 gemeinsam 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 können mich auf LinkedIn finden unter
https://linkedin.com/in/rbarrow Sie können unsere Salesforce-Angebote unter.
https://www.rapido-companion.app ansehen I hope to add better pre-build verification of __CAPGO_KEEP_0__ into my semantic release configuration. https://www.rapido.cloud in Entwicklung.
