Elegir el contexto
El resumen Tenant, Domain y Environment aparece en la barra inferior de estado operativo de Dova y Administrator. Haz clic en ese resumen para abrir el menú de usuario con los tres selectores. Conserva el distintivo y el color del entorno; no ocupa una franja superior ni duplica los campos.
El menú de usuario reúne Tenant, Domain y Environment. El contexto inicial es Development. Los entornos canónicos son Development, Test, Stage y Production; Stage aparece según la configuración y los permisos. Una ubicación Domain/Folder organiza la propiedad y el acceso, mientras el entorno separa las definiciones y sus ejecuciones. Compartir un Domain no concede permisos sobre otro entorno.
- Confirma el Tenant autorizado.
- Selecciona el Domain desde el menú de usuario.
- Elige Environment y espera a que termine la carga del contexto.
- Revisa el distintivo DEV, TEST, STAGE o PROD antes de editar o ejecutar.
Mappings, Sessions, Workflows, Connections y Monitor consultan el contexto seleccionado. Domain del editor identifica al propietario y queda bloqueado; Folder debe pertenecer a ese propietario. Para cambiar la ubicación utiliza la operación Move explícita y sus permisos.
Guardar, publicar y ejecutar
Save draft in DEV guarda el borrador en Development. Publish in DEV publica esa versión en el mismo entorno. Promote to Test abre una revisión separada del destino. Las etiquetas reflejan el entorno actual; guardar o publicar no traslada una definición a otro entorno ni ejecuta sus datos.
La autorización combina el permiso del módulo, el acceso al Domain y las capacidades del entorno y del artefacto. Production se presenta de solo lectura cuando no existe una autorización explícita. Un operador puede tener permiso de ejecución sin permiso de edición. Los controles no otorgan permisos por el nombre del entorno.
Cambiar sin mezclar borradores
Las pestañas, filtros, selección, borradores y posiciones se conservan por Tenant, Domain y Environment. Un cambio cancela lecturas anteriores y descarta respuestas obsoletas. Mientras una escritura está en curso no se puede cambiar de contexto. La restauración comprueba el artefacto y su autorización antes de recuperar un editor con cambios.
Cambiar de entorno conserva el trabajo local sin guardarlo ni publicarlo en el servidor. Los campos de contraseña y los archivos seleccionados no se trasladan a otro contexto. Guarda o cierra una Session con cambios antes de cambiar de Tenant. Si el servidor no confirma el contexto, la plataforma queda de solo lectura y ofrece Retry context.
Definiciones anteriores y recuperación
La actualización no convierte automáticamente todos los artefactos antiguos en Development. Las dependencias compartidas y las versiones publicadas pueden conservarse mediante pertenencia verificada y referencias exactas. Un artefacto ambiguo o compartido puede aparecer de solo lectura; los borradores locales anteriores permanecen pendientes de recuperación.
Para crear una copia editable usa Fork to Development. La revisión incluye las dependencias indirectas de Mapping, Session o Workflow. Selecciona para cada Connection una Connection compatible que ya pertenezca a Development. Dova no copia credenciales. El servidor vuelve a comprobar la revisión y rechaza cambios de origen o destino posteriores al preview. La copia se crea como borrador; Open in Development es una acción posterior explícita. Revisa y publica la copia antes de ejecutarla.
Consulta la guía de promoción para el flujo hacia Test y Production.
Permisos de entorno
La autorización combina permisos del módulo, acceso al Domain y capacidades del entorno. El catálogo actual contiene 23 permisos de entorno: etl.environments.view, etl.environments.{development,test,stage,production}.{view,edit,publish,run,runtime.manage}, etl.environments.promote y etl.environments.runtime.manage. Los permisos globales de lectura y Runtime conservan su alcance explícito; un permiso de un entorno no concede acceso a todos los demás. Administrar un módulo no sustituye estas capacidades.
ETL Developer puede trabajar en Development, Test y Stage y no tiene acceso a Production por defecto. Release Manager puede revisar los cuatro entornos y publicar en Test, Stage y Production para promover versiones autorizadas; no obtiene edición ni ejecución de Production. La promoción conserva el preview, las dependencias publicadas exactas y la aprobación explícita de Production. Los roles personalizados permiten asignar las capacidades necesarias por entorno. La identidad del usuario no se duplica por ambiente; verifica el rol activo, la membresía y sus permisos efectivos.
Los editores de Mapping, Session y Workflow de Production permanecen de solo lectura: las versiones aceptadas llegan mediante promoción. Configurar Connections existentes o nuevas de Production es una capacidad separada que exige etl.connections.manage y etl.environments.production.edit; no habilita edición de esos tres tipos ni modifica Connections legacy de solo lectura.
Trial público: pool Development gestionado
Un Trial público elegible sin una política explícita de Development puede utilizar automáticamente un pool público de Development gestionado por la plataforma. Solo incluye workers públicos compartidos verificados y autorizados para ese Trial; excluye workers privados y workers asignados a otros pools configurados. No guarda una política de Runtime ni concede permisos para administrarla.
Una política explícita de Development, incluso vacía, prevalece sobre esta opción automática. Test, Stage y Production conservan sus políticas. La capacidad depende de disponibilidad, perfil, cuotas y concurrencia; la elegibilidad no garantiza un worker disponible.
Kit GitOps por workspace
El kit GitOps 1.1.2 fija Tenant, Domain y Environment en consultas, reservas de drafts, publicaciones y leases. Usa source.environment y source.domainId para exportar; target.environment y bindings.domainId para importar. Los defaults son Development y General; el estado se conserva por destino. Lee el ejemplo Finance y la recuperación de estado. El autorado directo en Production requiere la promoción gobernada, no el comando de importación.
Antes de detener o retirar capacidad
Pause VM y Stop VM conservan sus comprobaciones de trabajos activos, worker predeterminado y capacidad compartida; revisa las referencias y el impacto antes de utilizarlos. Pause scheduling detiene nuevas asignaciones y permite terminar el trabajo actual. Para retirar definitivamente la VM, utiliza Remove VM and unlink y revisa su confirmación: después de verificar ausencia cloud, Dova limpia las asignaciones y muestra Unassigned sin borrar definiciones ni versiones publicadas. Antes de ejecutar de nuevo, asigna capacidad compatible explícitamente.
Las acciones requieren el permiso del módulo y Runtime del entorno correspondiente, o un permiso global concedido explícitamente. Una VM compartida requiere autorización sobre todos sus entornos.