Yellow mantiene la estructura (schemas y modelos) separada de los datos (instancias). Un beneficio directo: puedes construir y probar un schema en un tenant sandbox y luego promocionar la estructura resultante al tenant de producción sin exportar y reimportar JSON a mano. Esta guía recorre esa promoción.

Cuándo lo necesitas

Casos habituales:

  • Un modelo nuevo ha sido diseñado y probado en Acme Staging. Cuando está bien, quieres el mismo modelo — con el mismo UId, propiedades, restricciones y vistas — en Acme Producción.
  • Un schema existente ha ganado algunas propiedades nuevas en staging. Quieres pasarlas a producción sin tocar los datos de producción.
  • Un schema entero migra la propiedad de un sandbox personal a la organización, y de ahí al tenant principal de la organización.

El asistente de sincronización de schemas

La promoción la realiza una Schema sync job — un modelo del sistema que registra qué copiar, desde dónde y a dónde. Configuras una tarea por promoción.

Desde la página de la organización → Sync jobs → + Nueva schema sync job:

  1. Tenant origen — donde vive el schema bien probado (por ejemplo Acme Staging).
  2. Tenant destino — donde debe llegar el schema (por ejemplo Acme Producción).
  3. Schemas a sincronizar — elige uno o más. Puedes promocionarlos juntos si pertenecen a la misma área funcional.
  4. Modo — habitualmente aditivo (se añaden modelos y propiedades nuevos al destino; los existentes se reconcilian por UId). Algunas configuraciones también exponen un modo replace que borra primero la estructura del destino; úsalo con cautela.
  5. (Opcional) Dry run — ejecuta la tarea, informa de lo que cambiaría, pero no aplica. Hazlo siempre primero.

Guarda y ejecuta. El asistente informa de cada modelo y propiedad que toca.

Qué hace y qué no hace el asistente

Copia:

  • Modelos, propiedades, restricciones, vistas.
  • UIds de modelo y de propiedad (para que las referencias existentes en el destino sigan funcionando).
  • Enumeraciones del sistema referenciadas por el schema.

No copia:

  • Datos de instancia — las filas. Usa Copiar datos entre tenants para eso.
  • Configuración por tenant — marcadores, widgets, consultas guardadas.
  • Asignaciones de roles — los roles son por organización, no por tenant. Los miembros mantienen los roles que tenían en el destino.

Una secuencia de promoción segura

Para un tenant de producción real, sigue este orden:

  1. Congela los cambios estructurales en producción — asegúrate de que nadie edita el schema directamente en el destino mientras sincronizas.
  2. Ejecuta con dry-run — lee el diff con cuidado. Verifica que cada cambio de propiedad es intencional.
  3. Captura un snapshot — si tu organización guarda snapshots de tenant, captura uno del tenant destino antes de la ejecución en vivo.
  4. Ejecuta en vivo — haz la sincronización.
  5. Valida — abre el tenant destino, navega por unos cuantos modelos clave, crea una instancia de prueba, confirma que los formularios se renderizan correctamente.
  6. Descongela — deja entrar al equipo al destino.

Red de seguridad del versionado

Como los schemas están versionados (consulta Modelos), la forma anterior queda registrada tras una sincronización. Las instancias existentes en el destino siguen validando contra la versión del modelo con la que se crearon. Si la sincronización introduce un cambio de propiedad del que te arrepientes, puedes volver a ejecutar el asistente con un origen corregido — o, en el peor de los casos, pedir a un administrador de Yellow que haga rollback de la versión más reciente.

Relacionados