Ambientes (dev/test/prod) e promoção versionada

Selo de estado: Preview (limite atual do produto) · Atualizado em 2026-10-04. Fonte de estado: matriz de estados do produto. Sem SLA.

Quem constrói um painel quer testar antes de mostrar. O produto separa isso em três ambientes — dev, test e prod — e oferece um fluxo de promoção que leva a definição de um dashboard de um ambiente para o seguinte sem copiar dado, sem copiar credencial e sem edição manual no destino.

O que é um ambiente aqui#

Não existe um cadastro separado de "ambiente". Ambiente é uma convenção sobre o workspace: uma etiqueta [dev], [test] ou [prod] no nome do workspace (ou o nome inteiro sendo dev/test/prod). Workspaces irmãos pertencem à mesma organização — é ela que diz quais dev/test/prod formam um conjunto.

Sem etiqueta, o workspace é tratado como sem ambiente declarado e não entra em fluxo de promoção.

A regra de ordem#

A promoção é sempre para a frente e nunca pula etapa sem registro:

• dev → test e test → prod são as transições normais.
• dev → prod só com forçar explícito, e isso fica na auditoria.
• Recuar (prod → test) ou promover para o mesmo ambiente não é permitido — para voltar atrás existe o rollback (abaixo).

O fluxo: diff → aprovar → aplicar → rollback#

A promoção é construída sobre o BI-as-code: o diff é o mesmo dry-run do import; aplicar é o mesmo merge aditivo.

1. 1

   1. Gerar o plano (diff)

   No painel de origem, abra Promoção e escolha o workspace de destino. O produto exporta a definição, remove qualquer referência local do ambiente de origem (como o vínculo com o modelo semântico daquele workspace) e calcula, entidade por entidade, o que é novo, inalterado ou conflito.

2. 2

   2. Aprovar (outra pessoa)

   Quem aprova não pode ser quem promove — segregação de funções. Conflitos exigem estratégia explícita (manter_meu / usar_deles); sem escolha, a promoção não aplica nada.

3. 3

   3. Aplicar

   O merge é aditivo e idempotente: aplicar a mesma promoção duas vezes não muda nada na segunda (tudo vira inalterado). O estado do destino antes de aplicar fica guardado no plano.

4. 4

   4. Rollback

   Voltar é reescrever o snapshot capturado no passo 3. Também fica na auditoria.

Regra de ouro: credencial nunca viaja#

A exportação já nasce sem segredo (ela lê só a definição do painel). Mesmo assim, antes de aplicar, o produto varre o conteúdo e remove qualquer chave sensível (senha, token, chave de API, credencial de conta de serviço…) que tenha sido injetada em alguma configuração. Conexões, chaves e dados não migram; no destino você usa as conexões do próprio destino e roda o refresh.

O que fica registrado#

Cada promoção gera eventos na auditoria: quem pediu, quem aprovou, origem, destino, se foi forçada, resumo do plano aplicado e, se houver, o rollback.

Limites atuais#

• A promoção cobre dashboards e modelo (a definição). Pipelines têm o próprio versionamento (publicar e versionar) e não são promovidos por este fluxo.
• Os três ambientes são workspaces separados: cada um tem o próprio datalake, as próprias conexões e os próprios créditos.

Relacionado: BI-as-code · Organização e workspaces · Papéis (RBAC) · Auditoria.