Ambientes e promoção: diff, aprovação, rollback

Selo de estado: Preview (teto atual do produto) · Curso ACD-260 — Arquitetura de solução · Aula 3 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai decidir quantos ambientes a empresa sustenta e quem aprova a promoção — e vai saber o que o fluxo de promoção não cobre.

Vídeo#

Identificador: acd-260-03-ambientes-e-promocao · Duração-alvo: 8 min · Tela: /settings.

Roteiro (capítulos):

1. 0:00–1:00 — Ambiente é convenção, não cadastro (/settings → Workspace) — a etiqueta [dev]/[test]/[prod] e a organização que diz quem é irmão de quem.
2. 1:00–2:30 — Quantos ambientes a empresa paga (/billing) — cada ambiente é um workspace: plano, créditos e conexões próprios.
3. 2:30–4:20 — O fluxo diff → aprovar → aplicar → rollback (/dashboards) — merge aditivo, idempotente, e o snapshot que permite voltar.
4. 4:20–5:40 — Segregação de funções com time de uma pessoa — a decisão real: segundo aprovador ou dev → prod forçado e auditado.
5. 5:40–6:50 — O que não viaja — credencial, conexão, dado. E o que fica fora do escopo: pipelines.
6. 6:50–8:00 — O plano de promoção da Aurora (/settings) — dois ambientes, quem aprova, como se volta.

Conteúdo#

Ambiente é uma convenção sobre o workspace

Não existe cadastro de "ambiente". Ambiente é uma etiqueta no nome do workspace — [dev], [test], [prod] (ou o nome inteiro sendo um deles) — e é a organização que diz quais workspaces formam um conjunto de irmãos. Sem etiqueta, o workspace é sem ambiente declarado e não entra em fluxo de promoção.

A consequência arquitetural vem daí: como cada ambiente é um workspace separado, cada um tem o próprio datalake, as próprias conexões e os próprios créditos. Três ambientes não são três pastas: são três assinaturas, três franquias mensais e três conjuntos de credenciais para rotacionar.

A primeira decisão: quantos ambientes a empresa sustenta

A regra de ordem é fixa e não negociável: dev → test e test → prod são as transições normais; dev → prod só com "forçar" explícito, registrado na auditoria; recuar (prod → test) ou promover para o mesmo ambiente não é permitido — para voltar atrás existe o rollback.

Isso significa que "dois ambientes" é uma escolha legítima, mas ela se paga com uma promoção forçada a cada entrega. Se isso virou rotina diária, o desenho está dizendo que falta o test — e aí a decisão correta é criar o terceiro workspace, não normalizar o atalho.

O fluxo, e por que ele exige duas pessoas

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

1. Gerar o plano (diff). No painel de origem você escolhe o destino; o produto exporta a definição, remove referências locais do ambiente de origem (como o vínculo com o modelo semântico daquele workspace) e classifica, entidade por entidade, o que é novo, inalterado ou conflito.
2. Aprovar — outra pessoa. Quem aprova não pode ser quem promove. Conflitos exigem estratégia explícita (manter_meu / usar_deles); sem escolha, a promoção não aplica nada.
3. Aplicar. O merge é aditivo e idempotente: aplicar duas vezes não muda nada na segunda. O estado do destino antes de aplicar fica guardado no plano.
4. Rollback. Voltar é reescrever aquele snapshot — e também fica na auditoria.

Aqui está a decisão que mais aparece em PME: a segregação de funções exige duas pessoas, e o time tem uma. Não há como aprovar a própria promoção — é desenho, não obstáculo. As saídas honestas são duas, e você escolhe uma explicitamente no desenho:

• Nomear um segundo aprovador que não constrói — tipicamente o owner do workspace (o dono do negócio ou a controladoria). Ele não precisa saber montar painel; precisa ler o diff e dizer "pode". É a opção que preserva a rede de proteção.
• Aceitar dev → prod forçado, assumindo por escrito que cada entrega vai para a auditoria como promoção forçada. É aceitável em painel interno; não é aceitável em painel que o cliente final vê.

A 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 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.

No desenho isso tem duas consequências práticas: (1) cada ambiente precisa das suas próprias credenciais de origem — e de um plano de rotação próprio; (2) promover não enche o destino de dado. Depois de aplicar, alguém tem de rodar a carga lá. Quem não escreve isso no plano descobre na primeira demonstração com o painel vazio.

O que o fluxo não cobre

Pipelines fora do escopo é o detalhe que mais quebra implantação: o painel chega em prod esperando um mart que o pipeline de prod nunca criou. O plano de promoção precisa dizer, em uma linha, quem publica o pipeline no destino e em que ordem — antes do painel, sempre.

A decisão da Aurora

A Comércio Aurora tem uma pessoa construindo e um diretor que consome. Desenho que se defende: dois workspaces — Aurora [dev] e Aurora [prod], irmãos na mesma organização. A Maria promove; o owner aprova lendo o diff (não dev → prod forçado como rotina, porque o painel sustenta decisão de dinheiro). Os pipelines são publicados em prod antes da promoção do painel. O rollback é parte do procedimento, não improviso: se o diff aplicado quebrar o painel da diretoria, volta-se ao snapshot e se investiga em dev.

O que é recusado: um terceiro ambiente "porque é boa prática". Com um construtor e um aprovador, o test adicionaria uma assinatura e uma franquia sem adicionar leitor que valide — ele entra quando houver um segundo construtor ou um cliente externo vendo o painel.

Erros comuns de desenho

• Contar ambientes como pastas. São workspaces: plano, créditos e conexões multiplicados.
• Esperar que o dado viaje. Só a definição migra; no destino se conecta e se roda o refresh.
• Deixar a aprovação para quem promove. Recusado por desenho; decida quem é o segundo par de olhos antes da primeira entrega.
• Usar dev → prod como rotina silenciosa. Exige forçar, fica auditado — e se é rotina, falta o test.
• Esquecer os pipelines. Fora do escopo da promoção; publique-os primeiro no destino.
• Tratar o rollback como plano B informal. Ele é um passo do procedimento, com snapshot e auditoria.

Faça você mesmo#

O produto desta aula é um artefato de decisão: um plano de promoção de uma página. Use /settings → Workspace para conferir nomes e vínculo de organização; o resto é escrito.

1. Escreva quantos ambientes a empresa do seu caso sustenta e por quê, usando a tabela de arranjos — inclua o custo que você está aceitando.
2. Dê o nome exato de cada workspace com a etiqueta ([dev], [test], [prod]) e diga a qual organização eles pertencem.
3. Nomeie quem promove e quem aprova — pessoas diferentes, com nome e papel. Se não houver segunda pessoa, escreva qual das duas saídas você escolheu e o que está assumindo.
4. Escreva a ordem de publicação no destino: pipeline primeiro, painel depois, refresh em seguida.
5. Liste as credenciais que cada ambiente precisa ter próprias e quem as rotaciona.
6. Escreva o procedimento de rollback em três linhas: quem decide voltar, o que se reescreve, onde a investigação continua.
7. Marque o que fica fora do escopo da promoção, para ninguém esperar que viaje.

Você terminou quando: o plano cabe em uma página, tem nome de pessoa em "promove" e "aprova", diz a ordem pipeline → painel → refresh, e deixa explícito o custo da quantidade de ambientes que você escolheu.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• administracao/ambientes-e-promocao
• administracao/organizacao-e-workspaces
• administracao/planos
• bi/bi-as-code

Capacidades ensinadas#

C12.1 · C12.2 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".