1. Einführung
Bei Rapido Cloud (www.rapido.cloud), entwickle ich eine mobile Anwendung für Salesforce-Kunden, die ihre eigenen markenorientierten mobilen Anwendungen leicht ohne die schwierigen Schleifen des Salesforce Mobiles SDK oder des Salesforce Mobile Publishers bereitstellen können.
Diese mobile App habe ich auf einem 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, Ionic + Angular-Mobilanwendungen zu rekrutieren und zu pflegen.
Dieses Artikel erklärt meine Konzeption, meine Entscheidungen und meine 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, die mobilen Anwendungs-Bereitstellungen viel einfacher, viel schneller und flexibler zu machen als das Standard-Apple-AppStore/Google-PlayStore-Bereitstellungsverfahren.
I war zunächst besorgt über die Lernkurve, um dies erfolgreich zu machen, aber ich habe meine App leicht auf Apple TestFlight gebracht. Ich war dann in der Lage, Capgo CapacitorUpdater zu verwenden, um meine Updates viel schneller zu deployen.
Mein erster Anspruch und Testfall war, meine App für mich selbst zu deployen, um meine App als echte mobile App auf meinem eigenen Telefon zu testen, anstatt sie in einem mobilen Emulator oder in einem Simulator über die Nexus-Mobilbrowser zu testen, die von IIonic vorgeschlagen wurde. Das ist, weil meine App native Funktionen wie Geolocation oder Zugriff auf die Foto-Galerie und Kamera verwendet. Ohne die Erfahrung der Vergangenheit, eine Capacitor mobile App zu testen, war ich nicht sicher, ob alles richtig funktionieren würde : nichts besser, als die echte App in realen Bedingungen zu testen !
So Capgo CapacitorUpdater half mir, meine Anwendung auf meinem Mobilgerä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 leicht zu konfigurieren !
3. Meine Branching- 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 Branching- und Release-Modell organisieren
Für jede Anwendung, ob mobil, web oder Salesforce :
- entwickelt sich die Entwicklung auf brancht sich ab
feature/..., und sie werden inmainmergemain, welches die Referenz für die meisten Entwicklungszweige ist, außer für Wartung und spezifische Funktionen für benutzerdefinierte Lieferungen (mehr dazu unten) - Deployments werden ausgelöst aus Releasezweigen der möglicherweise sind :
productionPrereleasezweige (alpha,beta,nightlyetc.) und auch Kunden- oder Kontextspezifische Zweige für individuelle Lieferungen - Deployments werden durch einen Pull-Request ausgelöst der in einen Deployment-Zweig eingepflegt wird. Ich verwende keine tag-gesteuerten Deployments, 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 wie semantic-release funktioniert :
In einer Bereitstellungszweig, wenn semantic-release ausgelöst wird, wird es automatisch die neue Versionsnummer auf diesem Zweig berechnen, je nach 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 wird auch automatisch die Prerelease alpha, beta, etc. in der Versionsnummer einbeziehen.
Semantic release generiert die Änderungsliste aus Ihren Commits, indem es Fixes und Features wie in conventional Commits (siehe https://www.conventionalcommits.org/en/about) und in semantic release konfiguriert gruppiert.
Es wird auch alle Ihre Git (Github, in meinem Fall) fusionierten Pull-Anfragen und damit verbundenen Probleme mit Kommentaren verknüpfen, die auf das Tag und die Veröffentlichung verweisen. Schließlich wird in dieser Github Veröffentlichung es die Assets wie Quellcode code, Binärdateien falls erforderlich, CHANGELOG.md, etc. anfügen.
4. Zweige, Veröffentlichungen/Vorabveröffentlichungen, Kanäle in semantic release und in Capgo
Also, was ich von semantic release für Capgo-Bereitstellungen erwarte, ist Folgendes.
Ich erwarte, dass semantic release die Versionsnummer
Capgo haben ihre eigene Version der „Conventional Commits“ standard-version Tool entwickelt und dokumentiert, mit ihrem forkierten Repo 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 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 semantic-release ),
was auch (offensichtlich !) bedeutet, dass das großartig ist, und das ist eine Erleichterung für mich, weil ich semantic-release extensiv.
Auch möchte ich, dass semantic release App-Deployments auf verschiedenen Kanälen generiert
Wie oben erwähnt, benötige ich, um eine Vorelaborversion 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 darüber unten).
Semver-Versionen, die von semantic release auf Vorelaborversionen generiert werden, sehen wie 1.0.0-alpha.1. Erfolgliche Builds auf diesem Zweig werden die Buildnummer um 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 Vorelabor 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 To erhalten Sie die zahlreichen Uploadoptionen. Unter diesen verwenden wir die folgenden :
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-Login 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.
For jeden Merge auf einer Zweig, der in branches, wird semantic release einen Bereitstellung auslösen.
Setze CAPGO_APIKEY in den Geheimnissen deiner Repository.
Aktualisiere dein CAPGO_APPID hier.
Das Verhalten 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:branchesLegt die Konfiguration der Zweige (name), mapped to the Capgo channel (channelKanal (prerelease) zugeordnet sind und wie die Vorabversion des Versionsnummern genannt wird (branch.prerelease = "development"). Zum Beispiel, wennx.y.z-development.n- , wird die Versionsnummer, die von semantic release generiert wird, zu
alphaundalpha-nocapgoBranchen werden beide die App auf dasalphaKanal, aber mit unterschiedlichen Vorkonfigurationsnamen in der Versionsnummer - Zuweisungen an die Entwickler-Branchen
dev-rupertoderdev-paulwerden beide auf dasdevelopmentKanal auf Capgo, alles mit dem 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-Datei alsCHANGELOG.md@semantic-release/git: commiten Sie die folgenden Dateien, die durch die Ionic-Build-Ausführung und durch die Arbeit mit semantic release aktualisiert wurden (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- Ich baue noch nicht für Android,@semantic-release/github: anhängen Sie dasCHANGELOG.mdDatei an die Github-Veröffentlichung als Asset@semantic-release/exec: verwenden Sie diese 2 Befehle, um die App-Build-Vorbereitung vorzunehmen (prepareCmd) und dann effektiv die App-Bundle auf die Capgo-Server zu deployen (publishCmd)
Sie werden feststellen, dass keine Erklärungen erforderlich sind, um zu erklären, wie die Versionsnummer berechnet und inkrementiert werden soll, wie ein Changelog generiert werden soll, ein Github-Tag oder -Release, usw. : Alles wird durch semantic release standardmäßig gehandhabt, mit minimaler Konfiguration.
Mit XCode Cloud neue Binärdateien erstellen
Die Integration aller dieser Funktionen mit XCode Cloud zur Erstellung neuer Versionen der Anwendungsbinärdatei ist einfach (Ich baue noch nicht auf Google Play, aber die Build-Ausführung sollte ähnlich sein) :
- Ich habe einen XCode Cloud-Prozess eingerichtet, der bei Änderungen auf der von mir gewünschten Branch gebaut wird (z.B.
production) - auf dieser Branch, habe ich XCode Cloud eingerichtet, damit es nur dann baut, wenn es Änderungen auf dieser Branch gibt
CHANGELOG.mdDatei wird aktualisiert. Dies wird nach jeder Version, die durch semantic release generiert wird, aktualisiert. - 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 Branch setze ich eine Umgebungsvariable manuell mit dem Wert von
branch.channeleingesetzt inreleaserc.json(ja, dies 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-Branch bereitgestellt wird, wie zuvor erwähnt.
Erstellung von App-Binärdateien auf XCode Cloud mit Capgo Kanälen
7. Fazit
Zusammenfassend bin ich sehr glücklich, dass ich Capgo CapacitorUpdater in meine Standardpipeline für semantic release integrieren konnte, schnell innerhalb der Verzögerung der 14-Tage-Testzeit und das Ergebnis ist das Folgende :
- Die Versionsnummern der Pakete werden automatisch durch semantic release generiert und sind mit den Capgo-Servern kompatibel.
- semantic release deployt Capgo-Anwendungsprogrammbundles automatisch, wobei auch Capgo-Kanäle verwendet werden.
- Dies passt sich gut in die XCode Cloud-Builds von Anwendungsbinärdateien ein.
Nächste Schritte
I bin derzeit in der Entwicklungsphase dieses Apps. Ich werde es schnell über TestFlight (für iOS) an Tester bereitstellen. Unter Berücksichtigung der Capgo-Kraft werde ich sicherlich eine kostenlose Version der App im AppStore für Tests bereitstellen, die regelmäßig mit Capgo während der Tests aktualisiert wird. Ich werde dann eine weitere (bezahlte) Version der App im AppStore bereitstellen, unter einer anderen Aufzeichnung, und auch regelmäßig mit Capgo aktualisieren.
Ich hoffe, ich kann bessere Voraussetzungen für die Capgo-Prüfung in meine semantische Release-Konfiguration hinzufügen. bundle upload Die Voraussetzungen für die __CAPGO_KEEP_0__-Prüfung in meine semantische Release-Konfiguration hinzufü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äftsanalytiker und Berater, habe ich Erfahrung gesammelt. Ich habe Altius Services als COO und CTO mitgegründet und 13 Jahre lang als erfolgreicher Salesforce SI-Partner in Frankreich geleitet, bevor ich mich auf eine neue Abenteuer als Salesforce-Solopreneur mit meinem "Rapido Cloud"-Produktangebot begab. Sie finden mich auf LinkedIn unter https://linkedin.com/in/rbarrow
Sie können unsere Salesforce-Angebote unter https://www.rapido-companion.app.
Ich werde eine kostenlose Version der App im AppStore für Tests bereitstellen, die regelmäßig mit __CAPGO_KEEP_1__ während der Tests aktualisiert wird. Für zukünftige mobilen Apps, die mit Ionic + Angular + __CAPGO_KEEP_0__ entwickelt werden, habe ich jetzt eine saubere, einfache und reproduzierbare semantische Release-Pipeline. und https://www.rapido.cloud (in Entwicklung).
Weitermachen Sie von How Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwalten
Wenn Sie " Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwalten um die Lieferung von Live-Updates 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 zur Implementierungsdetail in Features, Updateverhalten zur Implementierungsdetail in Updateverhalten, und Update-Typen zur Implementierungsdetail in Update-Typen.
