Escolher o contexto
O resumo de Tenant, Domain e Environment aparece na barra inferior de status operacional do Dova e Administrator. Clique no resumo para abrir o menu do usuário com os três seletores. Ele mantém o distintivo e a cor do ambiente, sem faixa superior nem campos duplicados.
O menu do usuário reúne Tenant, Domain e Environment. O contexto inicial é Development. Os ambientes canônicos são Development, Test, Stage e Production; Stage aparece conforme a configuração e as permissões. A localização Domain/Folder organiza propriedade e acesso, enquanto o ambiente separa definições e execuções. Compartilhar um Domain não concede acesso a outro ambiente.
- Confirme o Tenant autorizado.
- Selecione o Domain no menu do usuário.
- Escolha Environment e aguarde o carregamento do contexto.
- Confira o distintivo DEV, TEST, STAGE ou PROD antes de editar ou executar.
Mappings, Sessions, Workflows, Connections e Monitor consultam o contexto selecionado. O Domain do editor identifica o proprietário e permanece bloqueado; Folder pertence a esse proprietário. Para alterar a localização, use a operação Move explícita e suas permissões.
Salvar, publicar e executar
Save draft in DEV salva o rascunho em Development. Publish in DEV publica essa versão no mesmo ambiente. Promote to Test abre uma revisão separada do destino. Os rótulos refletem o ambiente atual; salvar ou publicar não transfere uma definição entre ambientes nem executa seus dados.
A autorização combina a permissão do módulo, o acesso ao Domain e as capacidades do ambiente e do artefato. Production fica somente leitura sem autorização explícita. Um operador pode ter permissão de execução sem permissão de edição. O nome do ambiente não concede capacidades.
Mudar sem misturar rascunhos
Abas, filtros, seleção, rascunhos e posições são preservados por Tenant, Domain e Environment. A mudança cancela leituras anteriores e descarta respostas antigas. O contexto não muda enquanto houver uma gravação em andamento. A recuperação verifica o artefato e sua autorização antes de restaurar um editor com alterações.
Mudar de ambiente mantém o trabalho local sem salvar nem publicar no servidor. Campos de senha e arquivos selecionados não são transferidos a outro contexto. Salve ou feche uma Session alterada antes de mudar de Tenant. Se o servidor não confirmar o contexto, a plataforma fica somente leitura e oferece Retry context.
Definições anteriores e recuperação
A atualização não atribui automaticamente todos os artefatos antigos a Development. Dependências compartilhadas e versões publicadas podem continuar por meio de associação verificada e referências exatas. Um artefato ambíguo ou compartilhado pode ficar somente leitura; rascunhos locais anteriores permanecem pendentes de recuperação.
Use Fork to Development para criar uma cópia editável. A revisão inclui dependências indiretas de Mapping, Session ou Workflow. Selecione para cada Connection uma Connection compatível já pertencente a Development. Dova não copia credenciais. O servidor confere novamente a revisão e rejeita alterações de origem ou destino posteriores ao preview. A cópia é criada como rascunho; Open in Development é uma ação explícita posterior. Revise e publique antes de executar.
Consulte o guia de promoção para o fluxo até Test e Production.
Permissões de ambiente
A autorização combina permissões do módulo, acesso ao Domain e capacidades do ambiente. O catálogo atual contém 23 permissões de ambiente: etl.environments.view, etl.environments.{development,test,stage,production}.{view,edit,publish,run,runtime.manage}, etl.environments.promote e etl.environments.runtime.manage. Permissões globais de leitura e Runtime mantêm seu escopo explícito; uma permissão de um ambiente não concede acesso a todos os outros. Administrar um módulo não substitui essas capacidades.
ETL Developer pode trabalhar em Development, Test e Stage e não tem acesso a Production por padrão. Release Manager pode revisar os quatro ambientes e publicar em Test, Stage e Production para promoções autorizadas; isso não concede edição nem execução em Production. A promoção mantém preview, dependências publicadas exatas e aprovação explícita de Production. Funções personalizadas podem conceder as capacidades necessárias por ambiente. A identidade do usuário não é duplicada por ambiente; confira a função ativa, associação e permissões efetivas.
Editores de Mapping, Session e Workflow de Production permanecem somente leitura: versões aceitas chegam pela promoção. Configurar Connections existentes ou novas de Production é uma capacidade separada que exige etl.connections.manage e etl.environments.production.edit; não libera esses três editores nem Connections legacy somente leitura.
Trial público: pool Development gerenciado
Um Trial público elegível sem uma política explícita de Development pode usar automaticamente um pool público de Development gerenciado pela plataforma. Ele inclui apenas workers públicos compartilhados, verificados e autorizados para esse Trial; workers privados e workers associados a outros pools configurados ficam excluídos. Não salva uma política de Runtime nem concede permissão para administrá-la.
Uma política explícita de Development, mesmo vazia, tem prioridade sobre essa opção automática. Test, Stage e Production mantêm suas políticas. A capacidade continua sujeita a disponibilidade, perfil, cotas e concorrência; a elegibilidade não garante um worker disponível.
Kit GitOps por workspace
O kit GitOps 1.1.2 fixa Tenant, Domain e Environment em consultas, reservas de drafts, publicações e leases. Use source.environment e source.domainId para exportar; target.environment e bindings.domainId para importar. Os padrões são Development e General; preserve o estado por destino. Consulte o exemplo Finance e a recuperação do estado. A autoria direta em Production exige promoção governada, em vez do comando de importação.
Antes de parar ou retirar capacidade
Pause VM e Stop VM mantêm verificações de trabalhos ativos, worker padrão e capacidade compartilhada; revise referências e impacto antes de utilizá-los. Pause scheduling interrompe novas atribuições e permite concluir o trabalho atual. Para retirar a VM definitivamente, use Remove VM and unlink e revise a confirmação: após verificar ausência cloud, o Dova limpa atribuições e mostra Unassigned sem excluir definições nem versões publicadas. Atribua capacidade compatível explicitamente antes de executar novamente.
As ações exigem a permissão do módulo e Runtime do ambiente correspondente, ou uma permissão global concedida explicitamente. Uma VM compartilhada exige autorização em todos os seus ambientes.