Ambientes dev/test/prod, promoção, BYOC

Selo de estado: Preview (teto atual do produto) · Curso ACD-240 — Administração, segurança e governança · Aula 10 de 10 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai posicionar BYOC (chave cifrada = Preview; keyless = Roadmap) — e descrever o fluxo de promoção entre ambientes sem prometer o que ainda não existe.

Vídeo#

Identificador no manifesto: acd-240-10-byoc-ambientes-promocao · duração-alvo 7 min · tela do produto: /settings.

Roteiro de gravação (5 capítulos):

Conteúdo#

Ambiente aqui é uma convenção, não um cadastro

Não existe um cadastro separado de "ambiente". Ambiente é uma convenção sobre o workspace: uma etiqueta [dev], [test] ou [prod] no nome (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.

Como cada ambiente é um workspace separado, cada um tem o próprio datalake, as próprias conexões e os próprios créditos. Isso é consequência direta da aula 1: o workspace é a unidade de isolamento.

A ordem da promoção e o fluxo

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.

O fluxo tem quatro passos, construídos 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 workspace de 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 calcula, entidade por entidade, o que é novo, inalterado ou conflito.
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. 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. Rollback. Voltar é reescrever o snapshot capturado no passo 3 — e também fica na auditoria.

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

O escopo também é honesto: a promoção cobre dashboards e modelo (a definição). Pipelines têm o próprio versionamento e não são promovidos por este fluxo.

BYOC: onde cada metade roda

BYOC ("bring your own cloud") é sobre o data plane, nunca sobre o control plane. Em Configurações → Workspace existe o cartão "Cloud própria (Enterprise)", que descreve exatamente isso: o datalake (BigQuery + landing) roda no projeto GCP do cliente — os dados não saem da conta Google dele e os custos de nuvem são faturados direto pela Google para ele. Sem isso, o workspace usa o projeto compartilhado da plataforma. O control plane continua sendo nosso em qualquer arranjo: a aplicação, o cadastro, a orquestração e a interface seguem rodando na ingestia.io.

E aqui está o posicionamento que esta aula existe para fixar:

O modo de atualização ao vivo (rt) é o único recurso que depende de nuvem própria — batch existe em todos os planos e near_rt do Growth para cima.

Erros comuns

• Esperar que os dados viajem na promoção. Só a definição migra; no destino você conecta e roda o refresh.
• Aprovar a própria promoção. A segregação de funções recusa — é desenho, não obstáculo.
• Usar dev → prod como atalho rotineiro. Exige forçar explícito e fica registrado; se virou rotina, falta o test.
• Tentar "recuar" promovendo ao contrário. Recuo não existe: use o rollback.
• Contar pipelines no escopo da promoção. Eles têm versionamento próprio.
• Vender BYOC keyless. É Roadmap; o que existe hoje é BYOC com chave cifrada, em Preview.
• Prometer uptime ou RPO/RTO. Não foram medidos — não há número a prometer.

Estado do produto

Ambientes e promoção versionada são provados por testes, com teto público Preview. A confiabilidade empresarial — SLO/SLA, error budget, DR e BYOC keyless/WIF — é Roadmap: a arquitetura de federação de identidade não foi construída, e uptime, RPO e RTO não foram medidos. Por isso esta aula é de conhecimento: ela te dá o vocabulário para posicionar corretamente numa proposta — "o data plane pode rodar na sua conta GCP hoje, com chave cifrada, em Preview e sem SLA; keyless é roadmap; o control plane é sempre nosso" — sem transformar roadmap em promessa.

Faça você mesmo#

Esta aula é de conhecimento: não há exercício operacional. Leia, assista e responda à checagem rápida. Se quiser fixar o conteúdo sem mexer em nada, escreva por conta própria:

1. A frase de uma linha que você diria a um cliente sobre BYOC, separando chave cifrada (Preview) de keyless/WIF (Roadmap).
2. A frase que explica que o control plane é sempre nosso e só o data plane roda na conta do cliente.
3. Os quatro passos da promoção, na ordem, com a regra de quem aprova ≠ quem promove.
4. O que acontece se a mesma promoção for aplicada duas vezes.
5. A lista do que não viaja entre ambientes: conexões, chaves, dados — e por que a exportação nasce sem segredo.

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/planos
• administracao/ambientes-e-promocao
• administracao/organizacao-e-workspaces

Capacidades ensinadas#

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