Skip to main content

Documentation Index

Fetch the complete documentation index at: https://wiki.vivla.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Deployment

El proceso de deployment de Vivla esta completamente automatizado mediante GitHub Actions con workflows reutilizables. El sistema detecta inteligentemente el tipo de deploy necesario y ejecuta el pipeline correspondiente.

​
Workflows principales

​
Pipeline de Develop (develop.yml)

Trigger: push a la branch develop Este pipeline implementa una deteccion inteligente del tipo de deploy:
  1. Deteccion del tipo de deploy:
    • Si el mensaje de commit contiene [build] → full build
    • Si hay cambios en ios/, android/, app.config, package.json, eas.json → full build
    • Solo cambios en archivos JS/TS → OTA update
  2. Tests y lint siempre se ejecutan primero, independientemente del tipo de deploy
  3. Path OTA: publica un update al canal develop via eas update
  4. Path Full Build: builds secuenciales:
    • development (iOS + Android en paralelo)
    • preview (iOS, luego Android)
    • beta-prod (iOS, luego Android)
  5. Notificacion a Slack al finalizar
La deteccion inteligente optimiza los tiempos de CI. Si solo cambiaste codigo TypeScript, el deploy se resuelve en minutos con un OTA update en lugar de generar builds completos.

​
Pipeline de Production (main.yml)

Trigger: push a la branch main
  1. Tests y lint
  2. Build production iOS y Android en paralelo
  3. Notificacion a Slack
Los builds de produccion solo se disparan desde la branch main. Asegurate de que los tests pasen antes de mergear.

​
Pipeline de PR (pr.yml)

Trigger: PR a main o develop
  1. Solo tests y lint (no genera builds)
  2. Notificacion a Slack con estado del PR

​
Workflows reutilizables

Los workflows reutilizables tienen el prefijo _ y encapsulan la logica comun de cada tipo de build:
WorkflowDescripcion
_test.ymlLint, format check y tests
_build-development.ymlBuild de desarrollo
_build-preview.ymlBuild preview + submit a stores
_build-beta-prod.ymlBuild beta-prod + submit iOS
_build-production.ymlBuild produccion + submit a stores

​
OTA Updates

El proyecto usa expo-updates para distribuir actualizaciones over-the-air sin necesidad de generar nuevos binarios.

​
Canales de actualizacion

CanalDescripcion
developmentDesarrollo local
developEntorno de desarrollo compartido
beta-prodQA con API de produccion
productionUsuarios finales

​
Configuracion

  • Check automatico: ON_LOAD — la app busca actualizaciones al iniciar
  • Runtime version: igual a la version de la app (semver)

​
Scripts de OTA update

npm run update:development

​
Store submission

  • Los builds se envian a TestFlight via EAS Submit - Desde TestFlight se promociona a la App Store manualmente - Las credenciales de firma se gestionan remotamente por EAS

​
Flujo completo de release

El siguiente flujo describe el camino tipico de un cambio desde desarrollo hasta produccion:
  1. El desarrollador crea un PR contra develop → se ejecutan tests y lint
  2. Al mergear a develop → se detecta el tipo de deploy y se ejecuta el pipeline correspondiente
  3. QA valida en los builds de preview y beta-prod
  4. Se crea un PR de develop a main → tests y lint
  5. Al mergear a main → build de produccion + submit a stores
  6. Notificacion a Slack en cada paso del proceso