Capgo Umgebungsbest Practices: Staging mit einer mobilen App-ID

Teams wählen normalerweise eine von drei Ansätzen für mobile Umgebungen:

1. Zwei App-IDs (Produktion + Vorkonfiguration)
2. Eine App-ID + dynamische Umgebungswechsel
3. Eine App-ID + Capgo-Kanäle

Die ersten beiden können funktionieren, aber sie erzeugen langfristige Reibung. In realen Teams ist das Capgo-Kanalmodell normalerweise das sauberste.

Warum duplizierte App-IDs lästig werden

Mit "Using" com.myapp und com.myapp.beta scheint einfach, aber man bekommt schnell Duplikate:

• Zwei Releasepipelines
• Zwei Satze von Push-IDs, tiefen Links und Berechtigungszuordnungen
• Zwei Analytics- und Crash-Identitäten
• Divergierende Konfiguration und inkonsistente Verhaltensweisen zwischen Umgebungen

Man endet damit, zwei Produkte über Store-Konsolen, Teams und interne QA-Anweisungen zu verwalten.

Warum die Konfiguration bei Laufzeit oft verworren ist

Das "eine App-ID + Laufzeit-Switch"-Muster bedeutet normalerweise, dass die App Umgebungsvariablen oder Flags bei der Startzeit liest und APIs, Schlüssel und Aktualisierungsverhalten dynamisch umleitet.

Das funktioniert, bis:

• Die QA-Tests umgehen die vorgesehenen Abläufe, weil die Konfigurationszustände veraltet sind,
• jemand in der Produktion den falschen Endpunkt verwendet,
• Umgebungsdrift verursacht schwierig zu reproduzierende Fehler,
• Sie müssen auf einem Benutzergerät “Welche Konfigurationsversion verwendet dieser Binary?” debuggen.

Diese Komplexität wächst mit jedem Release und ist dort, wo Teams an Geschwindigkeit verlieren.

Die Capgo Methode: Eine App-ID, viele Kanäle

Capgo macht die Umgebungssteuerung explizit durch Kanäle:

• Halten Sie eine Produktions-App-ID in App Store / Play.
• Versenden Sie eine native Binärdatei für die “Shell” (bis native Änderungen eine wahre Rebuild erfordern).
• Routen Sie das Verhalten durch Kanäle, nicht durch dupizierte App-Identitäten.

In der Praxis bedeutet dies:

• production: alle Benutzer
• staging: interne QA und Release-Kandidaten
• beta: eingeladene Tester
• hotfix: Notfall-Patch-Track

Ihr TestFlight/Play-Intern-Test-App kann auf immer bleiben. Sie können JS/CSS/Asset-Updates dort wiederholt durch __CAPGO_KEEP_0__ durchführen, ohne eine neue native App zu veröffentlichen. staging forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

1) Native-Release-Baseline

Ihr letzter native Binary bleibt für viele JS-Iterationen gleich:

Sie bauen nur den native Binary neu, wenn Sie tatsächlich native Oberfläche geändert haben.

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

2) Verwenden Sie dedizierte Kanäle für Umgebungen

Veröffentlichen Sie Updates mit Kanälen:

2) Use dedicated channels for environments

bun run build
bunx @capgo/cli deploy --channel staging

Testen Sie auf QA, Probleme beheben, dann promoten:

bunx @capgo/cli promote vX.Y.Z --channel production

Wenn Sie eine explizite Versionsverwaltung bevorzugen:

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) Behalten Sie TestFlight immer als „vor-Prod“

In iOS-Workflows bedeutet dies, dass Ihre TestFlight-Version mit den Voreinstellungen für die Präproduktionsaktualisierungen verbunden bleiben kann:

• Keine häufigen native Submissionen für jede JS-Änderung.
• QA validiert immer nahe an der Produktion code über den Staging-Kanal.
• Produktionsnutzer erhalten nur die promoteten Produktionskanal-Pakete.

4) Verwenden Sie die Kanalwechsel nur für kontrollierte Workflows

Für fortgeschrittene Teams: Exponieren Sie kontrollierte Kanalwechsel für QA/Admin-Benutzer:

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

Dies ist optional. Die meisten Teams verwenden Kanalzuweisungen aus der Konsole und wechseln nur den Kanal für interne Benutzer, nicht für alle Kunden.

Betriebscheckliste

• Eine App-ID nur (keine Duplikate für Produktion/Staging-IDs)
• Eine Basislinien-Native-Build-Pipeline
• Kanalzuordnung dokumentiert (staging, beta, production, hotfix)
• Die Werbeverfolgung wird in CI/CD durchgesetzt
• Natives Rebuild nur bei echten native Änderungen
• Regelmäßige Überprüfung von Rollover

Praktische Vorteile

Diese Vorgehensweise entfernt Umgebungsdrift, reduziert die Build-Churn und beschleunigt die Reparaturen:

• Die QA erhält realistische Binärdateien (keine fiktiven „Staging-App“-Identitäten)
• Ihr TestFlight-Weg bleibt stabil
• Ihr Team vermeidet das „Zwei-App-ID-Debt“
• Sie können viele JS-nur-Fixes über Capgo schnell durchführen.

Das Ergebnis ist eine einfache Governance: weniger Artefakte, saubere Telemetrie und weniger Überraschungen in der Release-Operation.