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 mobilen Anwendungen zu deployen, ohne durch die schwierigen Schleifen von Salesforce Mobile __CAPGO_KEEP_0__ oder Salesforce Mobile Publisher gehen zu müssen.Rapido Cloud ist ein Unternehmen, das sich auf die Entwicklung von mobilen Anwendungen für Salesforce-Kunden spezialisiert hat.), 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, Entwickler und Maintainer von Ionic + Angular-Mobilanwendungen zu rekrutieren.
Dieser Artikel erklärt meine Konzeption, meine Entscheidungen und die Implementierung, die zu Capgo führen. semantic-release Ein sehr erfolgreicher "Keine-Brötchen"-Ansatz für die automatische Verwaltung aller Bereitstellungen via 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, mobile App-Bereitstellungen viel einfacher, viel schneller und flexibler zu machen als das Standard-Verfahren über den Apple AppStore/Google PlayStore.
Dies ist meine erste mobile Anwendung, die ich in die Stores pushen werde, nachdem ich mich in der Vergangenheit auf Webanwendungen konzentriert habe, 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 :
- Entwicklung findet statt auf
feature/...Branchen abmain, und sie werden inmaineingefügt, das ist die Referenz für die meisten Entwicklungszweige, außerhalb von Wartung und spezifischen Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten) - Deployments werden ausgelöst aus Releasezweigen welche sein können :
production, Vorabveröffentlichungszweige (alpha,beta,nightly, usw.) und auch Kunden- oder Kontextspezifische Zweige für individuelle Lieferungen - Aktivierungen werden durch einen Pull-Request ausgelöst der in einen Aktivierungs-Zweig eingebunden wird. Ich verwende keine tag-gesteuerten Aktivierungen, 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
Eine Randbemerkung zu wie semantic-release funktioniert :
In einem Aktivierungs-Zweig, wenn semantic-release ausgelöst wird, wird es automatisch die neue Versionsnummer auf diesem Zweig berechnen, je nach der Versionsnummer des vorherigen Tags auf dem Zweig und den gelieferten Fixes oder Features. Fixes werden eine neue Patchversion erzeugen, während Features eine neue Minorversion erzeugen. Es fügt auch automatisch die Vorabversion bei. alpha, betaetc. in der Versionsnummer.
Semantic release generiert die Changelog 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) fusionierten Pull-Anfragen und die 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, wenn nötig, CHANGELOG.mdetc.
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 geforkten 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-version-Repos. Sie haben auf ihrem Blog die Versionsnummerierung von Capgo in ihren Bereitstellungen dokumentiert (https://capgo.app/blog/wie-versionen-in-capgo-funktionieren/). JavaScript-Bundles folgen der 'standard' semver 'Semantic Versioning' (https://semver.org) die semantic-release auch (offensichtlich !)
So ist das großartig, und das ist eine Erleichterung für mich, weil ich semantic-release extensiv verwende.
Ich möchte auch, dass semantic release App-Deployments auf verschiedenen Kanälen generiert
Wie oben erwähnt, benötige ich eine Bereitstellung einer Prerelease-Version aus 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 semantic release auch unterstützt, also bin ich begeistert, sie zusammenzubringen. Diese passen auch in die verschiedenen Branch- Builds, die von XCode Cloud verwaltet werden (siehe mehr dazu unten).
Semver-Versionen, die von semantic release auf Prereleases generiert werden, sehen wie 1.0.0-alpha.1. Erfolgreiche Builds auf diesem Branch werden die Buildnummer um 1.0.0-alpha.2, etc. Zwar ist dies nicht explizit dokumentiert, aber diese Versionen werden 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 zu Capgo zu automatisieren, müssen Sie das Capgo CLI-Kommando 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- Der Capgo-Kanal ist der Capgo-Kanal, auf den wir deployen möchten (z.B.
alpha) - Die __CAPGO_KEEP_0__ ist durch semantic release generiert (z.B.
1.0.0-alpha.1) - CAPGO_APIKEY wird von Capgo zur eindeutigen Identifizierung Ihres CI/CD-Pipeline-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 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-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.
Für jeden Merge auf einer in __CAPGO_KEEP_0__ aufgelisteten Zweig branchesSemantische Release wird einen Deployment auslösen.
Setze CAPGO_APIKEY deinen Repository-Schlüssel ein.
Aktualisiere deinen CAPGO_APPID hier.
Die Funktionsweise von semantischer Release wird in ihrem .releaserc.json Konfigurationsdatei festgelegt.
Hier sind meine Einstellungen, die ich unten erkläre :
// .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 Branches (name) fest, die auf den Capgo Kanal (channel) und die Bezeichnung der Vorversion des Versionsnummern (prerelease) abgebildet werden. Zum Beispiel, wennbranch.prerelease = "development", wird das Versionsnummer von semantischer Releasex.y.z-development.n- Deployments auf 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, alle mit der gleichendevelopmentVorkonfigurations-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öffentlichung bearbeitet 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 als AssetCHANGELOG.mdfile to the Github release as an asset@semantic-release/exec) und dann, um die App-Bundle effektiv auf die __CAPGO_KEEP_0__-Server zu deployen (prepareCmdSie werden feststellen, dass es keine Umstände gibt, um zu erklären, 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 verwaltet, 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.
Integrieren Sie all das mit XCode Cloud, um neue Versionen der Anwendungsbinary zu erstellen, ist einfach (Ich baue noch nicht auf Google Play, aber die Build sollte ähnlich sein) :
Ich habe einen XCode Cloud-Prozess eingerichtet, um zu bauen, wenn es eine Änderung auf der von mir gewünschten Branch gibt (z.B.
- auf dieser Branch, habe ich XCode Cloud eingerichtet, um nur zu bauen, wenn das
production) - Datei aktualisiert wird. Dies wird nach jeder Version aktualisiert, die durch semantic release generiert wird.
CHANGELOG.mdDatei - 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.
Binärdateien von Apps auf XCode Cloud mit Capgo-Kanälen erstellen
7. Fazit
Insgesamt bin ich sehr zufrieden, 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-Anwendungsdateien automatisch, wobei auch Capgo-Kanäle verwendet werden
- Das passt gut zu den XCode Cloud-Builds von Anwendungsbinärdateien
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. Angesichts 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.
I hoffe, ich kann bessere Vorkompilierungsprüfungen für Capgo in meiner semantischen Release-Konfiguration hinzufügen. bundle upload Voraussetzungen
Ich habe jetzt eine saubere, einfache und reproduzierbare semantische Release-Pipeline für zukünftige mobilen Apps, die mit Ionic + Angular + Capacitor entwickelt wurden.
Autoren - Rupert Barrow
Mit über 22 Jahren Erfahrung bei Salesforce, als Kunde und Benutzer, als Partner und Integrator, Architekt, Entwickler, Geschäftsanalytiker und Berater, gründete ich Altius Services gemeinsam mit und leitete es 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
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.
Weitermachen Sie von Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet.
Wenn Sie " Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet. um die Live-Update-Übermittlung zu planen, verbinden Sie es mit Capgo Live Updates für den Produktworkflow in Capgo Live Updates, Übersicht für die Implementierungsdetails in Übersicht, Funktionen für die Implementierungsdetails in Funktionen, Update Verhalten zur Implementierungsdetails in Update Verhalten, und Update Typen zur Implementierungsdetails in Update Typen.
