1. Einleitung
Bei Rapido Cloud (www.rapido.cloud) entwickle ich eine mobile Anwendung für Salesforce-Kunden, damit sie ihre eigenen mobilen Anwendungen leicht ohne die schwierigen Schleifen des Salesforce Mobile SDK oder des Salesforce Mobile Publisher bereitstellen können.
Diese mobile App habe ich auf einer modernen und "standard"-Plattform mit weit verbreiteten Komponenten und Werkzeugen entwickelt, einschließlich Ionic 8, Angular 18, TypeScript, Capacitor und nun Capgo CapacitorUpdater. Diese sind einfacher zu handhaben für Kunden, die Salesforce-Plattform-Spezifika wie Lightning Web Components nicht 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 Capgo und semantic-release eine sehr erfolgreiche Selbstverständlichkeit für die automatische Verwaltung aller Bereitstellungen über Github Actions machen. 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-Deployments viel einfacher, viel schneller und flexibler zu machen als das Standard-Verfahren über den Apple AppStore/Google PlayStore.
Ich war eher besorgt über den Lernkurve, um dieses Projekt erfolgreich zu machen, aber ich konnte mein App auf Apple TestFlight leicht einrichten. Dann war ich in der Lage, Capgo CapacitorUpdater zu verwenden, um meine Updates viel schneller zu deployen.
Meine erste Anforderung und Testfälle war es, meine App für mich selbst zu deployen, um meine App als echte mobile App auf meinem eigenen Telefon zu testen, anstatt in einem mobilen Emulator oder in einem Simulator über die Nexus mobilen Browser vorgeschlagen von IIonic. Das ist, weil meine App native Funktionen wie Geolocation oder Zugriff auf die Photo Gallery und Camera verwendet. Ohne die Erfahrung im Testen einer Capacitor mobilen App, war ich nicht sicher, ob alles richtig funktionieren würde : nichts besser als die echte App, in realen Bedingungen zu testen !
Also Capgo CapacitorUpdater half mir, meine Anwendung auf meinem mobilen Gerät 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 Branching- und Release-Modell, und wie semantic-release hineinpasst
Also jetzt habe ich meine Lieferung an Capgo Server korrekt eingerichtet, ich muss dies automatisieren und in meine CI/CD Pipeline einfügen.
So organisiere ich meine Branching- und Release-Modell
Für jede Anwendung, unabhängig davon, ob es sich um eine mobile, Web- oder Salesforce-Anwendung handelt:
- Die Entwicklung erfolgt auf
feature/...Branchen abmain, und sie werden inmaineingefügt, das die Referenz für die meisten Entwicklungszweige ist, außer für Wartung und spezifische Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten) - Die Bereitstellung wird ausgelöst aus Releasezweigen Die Releasezweige können sein:
production, Vorkonfigurationszweige (alpha,beta,nightly, usw.) und auch benutzerdefinierte oder kontextspezifische Zweige für benutzerdefinierte Lieferungen - Deployments werden durch einen Pull-Request ausgelöst. Ich verwende keine tag-gesteuerten Bereitstellungen, 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
Ein Seitenhinhalt über die Funktionsweise von semantic-release :
In einer Bereitstellungsbranche wird, wenn semantic-release ausgelöst wird, automatisch die neue Versionsnummer auf dieser Branche berechnet, abhängig von der Versionsnummer der vorherigen Tag auf der Branche und den gelieferten Fixes oder Features. Fixes erzeugen eine neue Patchversion, während Features eine neue Minorversion erzeugen. Es wird auch automatisch der Prerelease alpha, beta, etc. in die Versionsnummer aufgenommen.
Semantic release generiert die Änderungsliste aus Ihren Commits, gruppiert Fixes und Features wie in konventionellen Commits (siehe https://www.conventionalcommits.org/en/about)
It will also update all your git (Github, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this Github release, it will attach assets such as source code, binaries if necessary, CHANGELOG.md4. Zweige, Releases/Prärelases, Kanäle in semantic release und in __CAPGO_KEEP_0__
Also, was ich von semantic release für Capgo-Deployments möchte, ist Folgendes.
So what I want semantic release to do for Capgo deployments is the following.
__CAPGO_KEEP_0__ haben ihre eigene Version der "Conventional Commits"-Methode entwickelt und dokumentiert.
https://Capgo.com/Cap-go/standard-version standard-version und ihre eigene standard-version (https://github.com/Cap-go/__CAPGO_KEEP_1__-standard-versionsowie capacitor-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionEs wird auch alle Ihre Git-Anfragen (__CAPGO_KEEP_0__, in meinem Fall) mit den zugehörigen Problemen und Kommentaren aktualisieren, die auf das Tag und die Veröffentlichung verweisen. Schließlich wird in dieser __CAPGO_KEEP_1__-Veröffentlichung die Anbindung von Assets wie Quellcode (__CAPGO_KEEP_2__), Binärdateien, falls erforderlich, etc. erfolgen. 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-arbeiten-in-capgo/) JavaScript-Bundles folgen der "standard" semver "Semantic Versioning" (https://semver.org) die auch (offensichtlich !) semantic-release Das ist großartig und ist für mich eine Erleichterung, da ich sie ausgiebig verwende.
Ich möchte auch, dass semantic release App-Bereitstellungen auf verschiedenen Kanälen generiert. semantic-release Wie oben erwähnt, benötige ich, um Voreinstellungen zu veröffentlichen, Versionen von Zweigen wie
etc., aber auch Kunden-spezifische Versionen auf Zweigen wie
etc. alpha, beta, nightly protectedTokens production-customer-jones, production-customer-doetargetLanguage
Capgo bietet die "Kanäle"-Funktion, die genau das tut, was auch semantic release unterstützt, also bin ich gespannt, sie zusammen zu machen. Diese passen auch zu den verschiedenen Branch-Builds, die von XCode Cloud verwaltet werden (siehe mehr dazu unten).
Semver-Versionen, die von semantic release auf Prereleases generiert werden, sehen aus wie 1.0.0-alpha.1. Bei diesem Branch werden die Buildnummern sukzessive um 1 erhöht, also 1.0.0-alpha.2, usw. Obwohl dies nicht explizit dokumentiert ist, unterstützt Capgo diese Versionsnummern, was für mich großartige Nachrichten ist: Ich werde semantic release-Kanäle und Prerelease verwenden, um mit Capgo-Kanälen Versionen meiner App 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 upload. Typieren Sie npx @capgo/cli@latest bundle upload --help , um die zahlreichen Upload-Optionen zu erhalten. Unter diesen 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 von 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 semantische Veröffentlichung + Capgo CapacitorUpdate-Einrichtung
Schließlich, wie passt sich alles zusammen?
App-Bundle-Versionen, die mit semantischer Veröffentlichung und Github Actions erstellt wurden
Semantische Veröffentlichungsautomatisierung mit Github Actions
Die Schönheit der semantischen Veröffentlichung 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 die semantische Veröffentlichung auf.
Für jeden Merge auf einer in branches, CAPGO_APIKEY semantische Veröffentlichung wird eine Bereitstellung ausgelöst.
Set CAPGO_APPID in den Geheimnissen Ihres Repositories.
Aktualisieren Sie Ihr
hier. . .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:branchesstellt die Konfiguration der Branches (name) ein, die auf den Capgo Kanal (channel) und die Bezeichnung der Vorkundenversion (prerelease) abgestimmt ist. Zum Beispiel, wennbranch.prerelease = "development", wird die von semantic release generierte Versionsnummer sein:x.y.z-development.n- Zu den Ziel-
alphaundalpha-nocapgoBranches wird die App auf denalphaKanal bereitgestellt, aber mit unterschiedlichen Vorkundenbezeichnungen in der Versionsnummer. - Zu den Entwickler-
dev-rupertoderdev-paulwerden beide auf dendevelopmentKanal auf Capgo, alles mit derselbendevelopmentVorabversionsschlüssel 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-semantic-Release-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: Füge die folgenden Dateien hinzu, die durch die Ionic-Build des Anwendungs und durch die semantische Release-Arbeit aktualisiert wurden (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android@semantic-release/github: füge dasCHANGELOG.mdDatei als Asset zur Github-Veröffentlichung hinzu@semantic-release/exec: Verwenden Sie 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 Umstände erforderlich sind, um zu erklären, wie die Versionsnummer berechnet und inkrementiert werden soll, wie eine Änderungsliste, ein Github-Tag oder Release generiert werden soll, usw. : Alles wird von semantic release standardmäßig verwaltet, mit minimaler Konfiguration.
Erstellung neuer Binärdateien mit XCode Cloud
Die Integration aller dieser Funktionen mit XCode Cloud zur Erstellung neuer Versionen des Anwendungsbinärs ist einfach (Ich habe noch nicht auf Google Play deployt, aber diese Build sollte ähnlich sein) :
- Ich habe einen XCode Cloud-Prozess eingerichtet, der gebaut wird, wenn auf der von mir gewünschten Branch eine Änderung vorgenommen wird (z.B.
production) - auf dieser Branch setze ich XCode Cloud ein, damit es nur gebaut wird, wenn der
CHANGELOG.mdDatei aktualisiert wird. Dies wird nach jeder von semantic release generierten Version aktualisiert. - Ich kann Builds auf verschiedenen Branches auslösen, um die Bereitstellung für verschiedene Kanäle zu simulieren. In jeder Konfiguration von XCode Cloud, die ich auf einem anderen Branch eingerichtet habe, setze ich eine Umgebungsvariable manuell mit dem Wert von
branch.channelgesetzt inreleaserc.json(ja, dies ist eine manuelle Duplikation) und dann könnte ich, wenn ich wollte, ein anderes AppStore-Anwendungsprogramm für jeden benutzerdefinierten Kundenanwendungsprogramm deployen, das aus einem benutzerdefinierten Release-Branch deployt wird, wie oben erwähnt.
Binärdateien für Apps auf XCode Cloud mit Capgo-Kanälen erstellen
7. Fazit
Zusammenfassend sage ich, dass ich sehr glücklich bin, Capgo CapacitorUpdater in meine Standardpipeline für semantische Releases integriert zu haben, schnell innerhalb der Verzögerung der 14-Tage-Testphase, und das Ergebnis ist wie folgt:
- Die Versionsnummern von Bundeln werden automatisch durch semantische Releases generiert und sind mit den Capgo-Servern kompatibel
- Semantische Releases deployen Capgo-Anwendungsdateien automatisch, wobei auch Capgo-Kanäle verwendet werden
- Dies passt gut zu den XCode-Cloud-Builds von Anwendungsdateien
Nächste Schritte
Ich bin derzeit in der Entwicklungsphase dieses Apps. Ich werde es schnell an Testern über TestFlight (für iOS) bereitstellen. 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. Dann werde ich eine weitere (bezahlte) Version der App auf dem AppStore bereitstellen, unter einem anderen Account, und auch diese regelmäßig mit Capgo aktualisieren.
Ich hoffe, ich kann bessere Prüfungen von Capgo vor dem Build in meine semantische Release-Konfiguration aufnehmen. bundle upload Ich habe jetzt eine saubere, einfache und reproduzierbare semantische Release-Pipeline für zukünftige mobilen 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.
__CAPGO_KEEP_1__
Ich verfüge über mehr als 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-Partner für Systemintegration 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)
