1. Einleitung
Bei Rapido Cloud (www.rapido.cloud), entwickle ich eine mobile App für Salesforce-Kunden, damit diese ihre eigene Marken-App einfach deployen können, ohne die komplizierten Prozesse des Salesforce Mobile SDK oder des Salesforce Mobile Publisher durchlaufen zu müssen.
Ich habe diese mobile App auf einer modernen „Standard“-Plattform mit weit verbreiteten Komponenten und Tools entwickelt, darunter Ionic 8, Angular 18, TypeScript, Capacitor und jetzt Capgo CapacitorUpdater. Das ist für Kunden, die keine Salesforce-Spezifika wie Lightning Web Components verwalten wollen, einfacher zu handhaben; zudem ist es für mich leichter und günstiger, Entwickler und Maintainer für Ionic + Angular Mobile Apps zu finden.
In diesem Artikel erkläre ich mein Design, meine Entscheidungen und die Implementierung, die Capgo und semantic-release zu einer extrem einfachen Lösung machen, um alle Deployments automatisch via Github Actions zu verwalten. Das alles wurde während der 14-tägigen kostenlosen Testphase von Capgo CapacitorUpdater entworfen, getestet und dokumentiert.
2. Warum Capgo nutzen? Warum semantic-release nutzen?
Capgo CapacitorUpdater hat mich mit dem Versprechen überzeugt, Mobile App Deployments viel einfacher, schneller und flexibler zu gestalten als den Standard-Prozess über den Apple AppStore oder Google PlayStore. Dies ist meine erste mobile App, die ich in die Stores bringe, nachdem ich mich in der Vergangenheit auf Web Apps konzentriert habe, die meist auf der Salesforce Experience Cloud entwickelt wurden.
Ich hatte anfangs etwas Angst vor der Lernkurve, um das Projekt erfolgreich umzusetzen, aber ich habe meine App ziemlich leicht in Apple TestFlight bekommen. Danach konnte ich Capgo CapacitorUpdater nutzen, um meine Updates viel schneller zu deployen.
Meine erste Anforderung und mein erster Testfall war es, meine App als echte mobile App auf meinem eigenen Handy zu testen, anstatt sie in einem Emulator oder über den von Ionic vorgeschlagenen Nexus-Browser zu testen. Das liegt daran, dass meine App native Features wie Geolocation oder den Zugriff auf die Fotogalerie und Kamera nutzt. Da ich keine Erfahrung mit dem Testen einer Capacitor mobilen App hatte, war ich unsicher, ob alles reibungslos funktionieren würde: Es gibt nichts Besseres, als die echte App unter realen Bedingungen zu testen!
So half mir Capgo CapacitorUpdater dabei, meine Anwendung live auf meinem Handy zu aktualisieren – nur eine Minute nachdem ich ein neues Feature oder einen Fix in meinem code gespeichert hatte: so erleichternd, flexibel und einfach einzurichten!
3. Mein Branching- und Release-Modell und wie semantic-release dazu passt
Da mein Deployment auf die Capgo Server nun korrekt funktioniert, muss ich diesen Prozess automatisieren und in meine CI/CD-Pipeline integrieren.
So organisiere ich mein Branching- und Release-Modell
Für jede Anwendung, egal ob Mobile, Web oder Salesforce:
- die Entwicklung findet statt auf
feature/...Branches vonmain, und sie werden gemergt inmain, was die Referenz für die meisten Development-Branches ist (außer Wartung und spezifischen Features für Custom-Deliveries; mehr dazu unten) - werden Deployments ausgelöst aus Release-Branches die sein können:
production, Prerelease-Branches (alpha,beta,nightly, etc.) sowie kunden- oder kontextspezifische Branches für individuelle Auslieferungen - Deployments werden durch einen Pull Request ausgelöst der in einen Deployment-Branch gemergt wird. Ich nutze keine Tag-basierten Deployments, da semantic-release die Tags und den ganzen Rest 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 kurzer Exkurs dazu, wie semantic-release funktioniert:
Wenn semantic-release in einem Deployment-Branch getriggert wird, berechnet es automatisch die neue Versionsnummer für diesen Branch – abhängig von der Versionsnummer des vorherigen Tags auf dem Branch und den enthaltenen Fixes oder Features. Fixes erzeugen eine neue Patch-Version, Features eine neue Minor-Version. Außerdem wird der Prerelease automatisch mit einbezogen alpha, beta, etc. in der Versionsnummer.
Semantic release erstellt das Changelog aus deinen Commits und gruppiert Fixes und Features gemäß den Conventional Commits (siehe https://www.conventionalcommits.org/en/about) und der Konfiguration in semantic release.
Es aktualisiert zudem alle gemergten Git-Pull-Requests (Github, in meinem Fall) und zugehörigen Issues mit Kommentaren, die auf das Tag und das Release verweisen. Schließlich werden bei diesem Github Release Assets wie der Source code, falls nötig Binaries, CHANGELOG.md, etc.
4. Branches, Releases/Pre-Releases und Channels in semantic-release und Capgo
Das ist es, was ich semantic release für Capgo Deployments ermöglichen möchte.
Ich möchte, dass semantic-release die Versionsnummer generiert
Capgo haben ihre eigene Version der „Conventional Commits“ entwickelt und dokumentiert standard-version Tools mit ihrem Fork entwickelt, standard-version (https://github.com/Cap-go/standard-version), und ihre eigenen capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) as well as capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) Repos. In ihrem Blog haben sie das Versionierungsschema dokumentiert, das Capgo bei Deployments nutzt ("https://capgo.app/blog/wie-versionierung-in-capgo-funktioniert/"). JavaScript-Bundles folgen dem „standard“ Semver „Semantic Versioning" ("https://semver.org"), welches semantic-release natürlich auch (logisch!)
Das ist großartig und eine echte Erleichterung für mich, da ich semantic-release intensiv nutze.
Ich möchte auch, dass semantic-release App-Deployments auf verschiedenen Channels generiert
Wie oben erwähnt, muss ich Pre-Release-Versionen aus Branches wie zum Beispiel deployen: alpha, beta, nightly etc., aber auch kundenspezifische Versionen auf Branches wie production-customer-jones, production-customer-doe, etc.
Capgo bietet das „Channels“-Feature an, das exakt dem entspricht, was semantic-release unterstützt. Ich freue mich darauf, beides zu kombinieren. Das passt auch perfekt zu den verschiedenen Branch-Builds, die von XCode Cloud verwaltet werden (siehe unten).
Semver-Versionsnummern, die semantic-release für Pre-Releases generiert, sehen so aus: 1.0.0-alpha.1. Nachfolgende Builds auf diesem Branch erhöhen die Build-Nummer auf 1.0.0-alpha.2, etc. Obwohl nicht explizit dokumentiert, werden diese Versionsnummern von Capgo unterstützt – eine super Nachricht für mich: Ich werde semantic-release Channels und Pre-Releases nutzen, um App-Versionen für Capgo Channels zu erstellen.
5. Wie kann ich mit Capgo meine App releasen?
Um das Deployment deiner App-Bundles zu Capgo zu automatisieren, nutzt du den Capgo CLI Befehl bundle upload. Gib npx @capgo/cli@latest bundle upload --help ein, um die verschiedenen Upload-Optionen zu sehen. Wir werden folgende nutzen:
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL ist der Capgo Channel, in den wir deployen wollen (z. B.
alpha) - VERSION wird von semantic release generiert (z. B.
1.0.0-alpha.1) - CAPGO_APIKEY wird von Capgo bereitgestellt, um deinen CI/CD-Pipeline-Login eindeutig zu identifizieren
- CAPGO_APPID wird von Capgo bereitgestellt, um deine App eindeutig zu identifizieren (z. B.
com.mystartup.mysuperapp)
6. Mein semantic release + Capgo CapacitorUpdate Setup
Und wie passt das alles zusammen?
App-Bundle-Versionen, gebaut mit semantic release und Github Actions
Semantic-Release-Automatisierung mit Github Actions
Das Schöne an semantic release ist, dass die Deployment-Automatisierung als Github Action Workflow sehr einfach ist. Auf anderen CI/CD-Plattformen sieht das sehr ähnlich aus.
# ./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 }}Das installiert nur die NodeJS-Umgebung und ruft dann semantic release auf.
Für jeden Merge auf einen Branch, der aufgeführt ist in branches, löst semantic release ein Deployment aus.
Setze CAPGO_APIKEY in den Secrets deines Repositories.
Aktualisiere deinen CAPGO_APPID hier.
Das Verhalten von semantic release wird in der .releaserc.json Konfigurationsdatei festgelegt.
Hier sind meine Einstellungen, unten erklärt:
// .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 Branch-Konfiguration fest (name), gemappt auf den Capgo Channel (channel) und wie die Prerelease-Versionsnummer benannt wird (prerelease). Wenn zum Beispielbranch.prerelease = "development", wird die von semantic release generierte Versionsnummerx.y.z-development.n- Deployments an den
alphaundalpha-nocapgoBeide Branches deployen die App auf denalphaChannel, aber mit unterschiedlichen Prerelease-Namen in der Versionsnummer - Deployments an die Developer-Branches
dev-rupertoderdev-pauldeployen beide auf dendevelopmentChannel auf Capgo, alle mit demselbendevelopmentPrerelease-Keyword in der Versionsnummer
verifyConditions: In der ersten Phase von semantic release wird geprüft, ob der Zugriff auf Github korrekt ist. Ich möchte hier später noch einen Auth-Check für den Capgo CLI hinzufügen@semantic-release/commit-analyzer: Standard semantic release Setup – siehe Dokumentation (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: die Changelog-Datei generieren alsCHANGELOG.md@semantic-release/git: committe die folgenden Dateien, die durch den Ionic-Build der Anwendung und den semantic-release-Prozess aktualisiert wurden (package.json,CHANGELOG.mdundios/App/App.xcodeproj/project.pbxproj- (Ich baue aktuell noch nicht für Android)@semantic-release/github: hänge dieCHANGELOG.mdGithub Release-Datei als Asset an@semantic-release/exec: nutze diese 2 Befehle, um den App-Build vorzubereiten (prepareCmd) und das App-Bundle anschließend an die Capgo Server zu deployen (publishCmd)
Du wirst merken, dass man sich nicht darum kümmern muss, wie die Versionsnummer berechnet und erhöht wird, wie ein Changelog, ein Github Tag oder Release erstellt wird usw.: Alles wird standardmäßig von semantic-release mit minimaler Konfiguration erledigt.
Neue Binaries mit Xcode Cloud bauen
Die Integration mit XCode Cloud zum Bauen neuer Versionen der App-Binary ist einfach (ich deploye noch nicht auf Google Play, aber der Build sollte ähnlich sein):
- Ich habe einen XCode Cloud Prozess eingerichtet, der baut, sobald es eine Änderung im Branch gibt, den ich dafür nutzen möchte (z. B.
production) - in diesem Branch habe ich XCode Cloud so eingestellt, dass es nur baut, wenn die
CHANGELOG.mdDatei aktualisiert wird. Diese wird nach jeder von semantic-release generierten Version aktualisiert. - Ich kann Builds auf verschiedenen Branches triggern, um das Deployment für unterschiedliche Channels zu simulieren. In jeder XCode Cloud Build-Konfiguration auf einem anderen Branch setze ich manuell eine Umgebungsvariable mit dem Wert von
branch.channelfestgelegt inreleaserc.json(ja, das ist eine manuelle Duplizierung). Wenn ich wollte, könnte ich so – wie bereits erwähnt – für jede kundenspezifische App, die von einem eigenen Release-Branch kommt, eine andere AppStore-App deployen.
App-Binaries auf XCode Cloud mit Capgo Channels bauen
7. Conclusion
Zusammenfassend lässt sich sagen, dass ich sehr froh bin, Capgo CapacitorUpdater so schnell – noch innerhalb der 14-tägigen Testphase – in meine Standard-Semantic-Release-Pipeline integriert zu haben. Das Ergebnis ist folgendes:
- Bundle-Versionsnummern werden automatisch durch semantic-release generiert und sind mit den Capgo Servern kompatibel
- semantic-release deployt automatisch Capgo App-Bundles und nutzt dabei auch Capgo Channels
- das lässt sich hervorragend in XCode Cloud Builds von App-Binaries integrieren
Nächste Schritte
Ich befinde mich aktuell in der Entwicklungsphase dieser App. Ich werde sie schnell über TestFlight (für iOS) für Tester verfügbar machen. Angesichts der Power von Capgo werde ich definitiv eine kostenlose Version der App für Tests im AppStore deployen, die während der Tests regelmäßig via Capgo aktualisiert wird. Danach werde ich eine weitere (kostenpflichtige) Version der App unter einem anderen Record im AppStore bereitstellen und auch diese regelmäßig mit Capgo updaten.
Ich hoffe, eine bessere Pre-Build-Verifizierung der Voraussetzungen für Capgo bundle upload in meine semantic-release-Konfiguration einzubauen.
Ich habe nun eine saubere, einfache und reproduzierbare semantic-release-Pipeline für zukünftige mobile Apps mit Ionic + Angular + Capacitor.
Autor – Rupert Barrow
Ich habe über 22 Jahre Erfahrung mit Salesforce – als Kunde und Nutzer, als Partner und Integrator, Architekt, Entwickler, Business Analyst und Consultant. Ich habe Altius Services, einen erfolgreichen Salesforce-SI-Partner in Frankreich, 13 Jahre lang als COO und CTO mitgegründet und mitgeleitet, bevor ich mich als Salesforce-Solopreneur mit meinem Rapido Cloud Produktangebot.
Sie finden mich auf LinkedIn unter https://linkedin.com/in/rbarrow.
Unsere Salesforce-Angebote finden Sie unter https://www.rapido-companion.app und https://www.rapido.cloud (in Entwicklung).
Weiterlesen: So verwaltet Rapido Cloud Semantic Release mit Capgo CapacitorUpdater
Wenn du es nutzt Wie Rapido Cloud Semantic Release mit Capgo CapacitorUpdater verwaltet um die Auslieferung von live update zu planen, verbinde sie mit Capgo Live Updates für den Produkt-Workflow in Capgo Live Updates, Übersicht für die Implementierungsdetails in Overview, Funktionen für die Implementierungsdetails in Features, Update-Verhalten für die Implementierungsdetails in Update Behavior und Update-Typen für die Implementierungsdetails in Update Types.
