Buenas prácticas de entornos Capgo: Staging con un único App ID móvil

Los equipos suelen elegir uno de tres enfoques para los entornos móviles:

1. Dos IDs de app (producción + preproducción)
2. Un app ID + cambio dinámico de entorno en tiempo de ejecución
3. Un ID de app + canales Capgo

Los dos primeros pueden funcionar, pero generan fricción a largo plazo. En equipos reales, el modelo de canales Capgo suele ser el más limpio.

Por qué los IDs de app duplicados generan ruido

Usando com.myapp y com.myapp.beta parece simple, pero rápidamente surge la duplicación:

• Dos pipelines de release
• Dos conjuntos de push IDs, deep links y mapeo de entitlements
• Dos identidades de analítica y crashes
• Config divergente y comportamiento inconsistente entre entornos

Acabas gestionando dos productos en consolas de tiendas, equipos e instrucciones de QA interno.

Por qué cambiar la config en runtime suele ser un desastre

El patrón de “un solo app ID + conmutación en runtime” suele significar que tu app lee variables de entorno o flags al inicio y reencamina dinámicamente APIs, keys y el comportamiento de actualizaciones.

Esto funciona hasta que:

• QA empieza a saltarse flujos previstos porque la config está obsoleta,
• alguien usa el endpoint incorrecto en producción,
• el drift de entornos causa bugs difíciles de reproducir,
• necesitas debuggear “¿qué versión de config usa este binario?” en el dispositivo de un usuario.

Esa complejidad crece con cada release y es donde los equipos pierden velocidad.

El método Capgo: un app ID, muchos channels

Capgo hace explícito el control de entornos con channels:

• Mantén un único app ID de producción en App Store / Play.
• Envía un único binario nativo para el “shell” (hasta que los cambios nativos requieran un rebuild real).
• Enruta el comportamiento por channel, no duplicando la identidad de la app.

En la práctica, esto significa:

• production: all users
• staging: QA interno y candidatos a release
• beta: testers invitados
• hotfix: canal de parches de emergencia

Tu app de pruebas internas de TestFlight/Play puede seguir activa staging para siempre. Actualizas JS/CSS/assets allí repetidamente mediante Capgo sin publicar una nueva app nativa.

Estructura recomendada en la práctica

1) Baseline de release nativo

Tu último binario nativo se mantiene igual durante muchas iteraciones de JS:

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

Solo recompilas el binario nativo cuando realmente cambias la parte nativa.

2) Usa canales dedicados para cada entorno

Publica actualizaciones con canales:

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

Prueba en QA, corrige errores y luego promociona:

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

Si prefieres un versionado explícito:

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

3) Mantén TestFlight como “siempre pre-prod”

En flujos de iOS, esto significa que tu build de TestFlight puede seguir asociado a actualizaciones de pre-producción:

• Sin envíos nativos frecuentes por cada cambio en JS.
• QA siempre valida code casi de producción mediante el canal de staging.
• Los usuarios de producción solo reciben bundles promocionados del canal de producción.

4) Usa el cambio de canales solo para flujos controlados

Para equipos avanzados, expón cambios de canal controlados para usuarios de QA/admin:

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

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

Esto es opcional. La mayoría de los equipos usa asignaciones de canal desde el dashboard y solo cambia de canal para usuarios internos, no para todos los clientes.

Checklist operativo

• Un solo app ID (sin IDs duplicados de producción/staging)
• Un pipeline base de Native Build
• Mapeo de canales documentado (staging, beta, production, hotfix)
• Ruta de promoción aplicada en CI/CD
• Rebuild nativo solo ante cambios nativos reales
• Rollback probado regularmente

Beneficio práctico

Este enfoque elimina el drift de entornos, reduce el churn de builds y acelera los fixes:

• QA recibe binarios reales (sin la falsa identidad de "app de staging"),
• tu ruta de TestFlight se mantiene estable,
• tu equipo evita la "deuda de dos App IDs",
• puedes lanzar muchos fixes solo de JS vía Capgo rápidamente.

El resultado final es una gobernanza más simple: menos artefactos, telemetría más limpia y menos sorpresas en las operaciones de release.

Continúa desde Capgo Mejores prácticas de entornos: Staging con un solo App ID móvil

Si estás usando Buenas prácticas de entornos Capgo: Staging con un único App ID móvil para planificar el enrutamiento de canales y el despliegue gradual, conéctalo con Canales para los detalles de implementación en Channels, Canales para los detalles de implementación en Channels, Canales para los detalles de implementación en Channels, Solución de beta testing para el workflow del producto en la solución de beta testing, y Solución de segmentación por versión para el workflow del producto en la solución de segmentación por versión.