1. Einleitung
Bei Rapido Cloud (www.rapido.cloud) entwickle ich eine mobile Anwendung für Salesforce-Kunden, um es ihnen leicht zu machen, ihre eigenen brandgeladenen mobilen Anwendungen ohne die schwierigen Schleifen des Salesforce Mobile SDK oder des Salesforce Mobile Publisher zu deployen.
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 Konzeption, meine Entscheidungen und meine 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 mobilen App-Bereitstellungen 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, 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 für mich selbst zu deployen, um meine App als echte mobile App auf meinem eigenen Handy zu testen, anstatt in einem mobilen Emulator oder in einem Simulator über den Nexus-Mobilbrowser, der 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, eine Capacitor mobile App getestet zu haben, war ich mir nicht sicher, ob alles richtig funktionieren würde : nichts besser, als die echte App in realen Bedingungen zu testen !
Der Capgo CapacitorUpdater half mir, meine Anwendung auf meinem Handy 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 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 organisieren
Für jede Anwendung, sei es mobile, Web oder Salesforce :
- entwickelt sich auf
feature/...Branchen abmain, und sie werden inmaindas ist die Referenz für die meisten Entwicklungszweige, außer für Wartung und spezifische Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten) - werden die Bereitstellungen ausgelöst aus Releasezweigen die möglicherweise :
production, Vorkundenzweige (alpha,beta,nightly, usw.) und auch Kunden- oder Kontextspezifische Zweige für individuelle Lieferungen - Aktualisierungen werden durch einen Pull-Request ausgelöst da ich Pull-Request-Aktualisierungen verwende, weil semantic-release die Tags und alles andere für mich verwaltet.
Im Grunde handelt es sich um die Gitlab-Flow :
Gitlab-Flow - Quelle https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
Eine Randbemerkung zu wie semantic-release funktioniert :
In einem Aktualisierungs-Zweig, wenn semantic-release ausgelöst wird, wird es automatisch die neue Versionsnummer auf diesem Zweig berechnen, abhängig von der Versionsnummer des vorherigen Tags auf dem Zweig und den gelieferten Fixes oder Features. Fixes werden eine neue Patchversion erstellen, während Features eine neue Minorversion erstellen. Es fügt auch automatisch die Vorkunden hinzu. alpha, betaetc. in der Versionsnummer.
Semantic release generiert die Änderungsliste aus Ihren Commits, gruppiert Fixes und Features wie in conventioenellen Commits (siehe https://www.conventionalcommits.org/en/about) und konfiguriert in semantic release.
Es wird auch alle Ihre Git (Github, in meinem Fall) verschmolzenen Pull-Anfragen und damit verbundenen Issues mit Kommentaren verknüpfen, die auf das Tag und die Release verweisen. Schließlich wird in dieser Github Release es die Assets wie Quellcode code, Binärdateien falls erforderlich CHANGELOG.mdetc.
4. Zweige, Releases/Prereleases, 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 geforkten 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-versionebenfalls capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionRepos haben. Sie haben auf ihrem Blog die Versionsnummerierung von Capgo in ihren Bereitstellungen dokumentiert (https://capgo.app/blog/how-version-work-in-capgo/). JavaScript-Bundles folgen der "standard" semver "Semantic Versioning" (https://semver.org), die semantic-release ebenfalls (offensichtlich !)
Das ist großartig und ist mir ein Riesengeschenk, weil ich sie semantic-release extensiv verwende
Ich möchte auch, dass semantic release App-Deployments auf verschiedenen Kanälen generiert
Wie oben erwähnt, muss ich eine Prerelease-Version 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 zu den verschiedenen Zweig-Builds, die von XCode Cloud verwaltet werden (siehe mehr dazu unten).
Semver-Versionszahlen, die von semantic release auf Prereleases generiert werden, sehen wie 1.0.0-alpha.1. Bei jedem auf diesem Zweig erstellten Build wird die Buildnummer um 1 erhöht, also 1.0.0-alpha.2, etc. Obwohl dies nicht explizit dokumentiert ist, werden diese Versionszahlen 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 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 Bereitstellungsautomatisierung 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 im Geheimnisspeicher Ihres Repositories.
Aktualisieren Sie CAPGO_APPID zurück.
Das Verhalten von semantic release wird in seinem .releaserc.json Konfigurationsdatei festgelegt.
Hier sind meine Einstellungen, erläutert 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, wie die Konfiguration von Branchen (name) auf den Capgo Kanal (channel) und wie die Vorkundenversion des Versionsnummerns genannt wird (prerelease). Zum Beispiel, wennbranch.prerelease = "development", wird die Versionsnummer, die von semantic release generiert wird, seinx.y.z-development.n- Bereitstellungen an das
alphaundalpha-nocapgoZweige werden beide die App auf dasalphaKanal, aber mit unterschiedlichen Vorkassenamen in der Versionsnummer - Zuweisungen auf die Entwicklerzweige
dev-rupertoderdev-paulwerden beide auf dasdevelopmentKanal auf Capgo, alle mit derselbendevelopmentVorkassenwort 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-Datei alsCHANGELOG.md@semantic-release/git: Füge die folgenden Dateien hinzu, die durch die Ionic-Build der Anwendung 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: füge dem __CAPGO_KEEP_0__-Release als AssetCHANGELOG.mdfile to the Github release as an asset@semantic-release/exec) und dann effektiv die App-Bundle auf die __CAPGO_KEEP_0__-Server 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 bei Änderungen auf der von mir gewünschten Branch gebaut wird (z.B.
- auf dieser Branch, habe ich XCode Cloud eingerichtet, damit es nur gebaut, wenn der
production) - Datei aktualisiert wird. Diese wird nach jeder durch semantic release generierten Version aktualisiert.
CHANGELOG.mdBuilding new binaries with XCode Cloud ist einfach (Ich baue noch nicht auf Google Play, aber die Build-Operation sollte ähnlich sein): - 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.channelfestgelegt inreleaserc.json(ja, das ist eine manuelle Duplikation) und dann, wenn ich wollte, könnte ich ein anderes AppStore-Anwendungsprogramm für jeden benutzerdefinierten Kundenanwendungsprogramm bereitstellen, das von einem benutzerdefinierten Release-Zweig bereitgestellt wird, wie bereits erwähnt wurde.
Binärdateien von Apps auf XCode Cloud erstellen mit Capgo Kanälen
7. Fazit
Zusammenfassend 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 von Bundeln werden automatisch durch Semantik-Release generiert und sind mit den Capgo-Servern kompatibel
- Semantik-Release deployt Capgo-Anwendungs-Dateien automatisch, wobei auch Capgo-Kanäle verwendet werden
- Das passt gut in die XCode Cloud-Builds von Anwendungs-Dateien
Nächste Schritte
Ich bin 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 Macht von Capgo, werde ich sicherlich ein kostenloses Anwendungsprogramm auf den AppStore bereitstellen, um es zu testen, das regelmäßig mit Capgo aktualisiert wird. Ich werde dann ein anderes (bezahltes) Anwendungsprogramm auf den AppStore bereitstellen, unter einem anderen Account, und auch das regelmäßig mit Capgo aktualisieren.
Ich hoffe, ich kann bessere Vorkompilationsprüfungen von Capgo in meine semantische Release-Konfiguration hinzufügen. bundle upload Voraussetzungen
Ich habe jetzt eine saubere, einfache und reproduzierbare semantische Release-Pipeline für zukünftige mobile Apps, die mit Ionic + Angular + Capacitor entwickelt werden.
Autor - Rupert Barrow
Ich habe über 22 Jahre Erfahrung mit Salesforce, als Kunde und Nutzer, als Partner und Integrator, Architekt, Entwickler, Geschäftsanalytiker und Berater. Ich gründete und leitete gemeinsam Altius Services als COO und CTO für 13 Jahre, ein erfolgreiches Salesforce-Partnerunternehmen in Frankreich, bevor ich mich auf eine neue Abenteuer als Salesforce-Solopreneur mit meinem Rapido Cloud Produktangebot
beschäftigte. Sie können mich auf LinkedIn finden unter.
https://linkedin.com/in/rbarrow Sie können unsere Salesforce-Angebote auf https://www.rapido-companion.app","ansehen. https://www.rapido.cloud in Entwicklung.
