Rascunho × publicado; versões

Selo de estado: Preview (teto atual do produto) · Curso ACD-340 — Publicação, distribuição, RLS e BI-as-code · Aula 1 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai publicar e reverter.

Vídeo#

Identificador no manifesto: acd-340-01-rascunho-publicado-versoes · duração-alvo 6 min · tela do produto: /dashboards.

Roteiro (capítulos):

1. 00:00–00:45 — Por que existe rascunho e por que existe publicado (/dashboards).
2. 00:45–02:00 — Editar o rascunho sem derrubar quem já vê o painel; o botão Publicar no cabeçalho.
3. 02:00–03:30 — O diff de pendências antes de confirmar a nova versão.
4. 03:30–05:00 — Histórico de versões e o botão Restaurar (/dashboards/[id]/versoes).
5. 05:00–06:00 — Encerramento e o exercício da aula.

Conteúdo#

No ingestia.bi, editar um dashboard e publicar um dashboard são duas ações diferentes, de propósito. O rascunho é a superfície de trabalho: só quem tem permissão de edição a vê, e ela muda a cada clique — mover um visual, trocar uma cor, adicionar um filtro. O publicado é a versão congelada que os leitores do painel enxergam: maria (dona do workspace) pode passar a tarde inteira reorganizando o painel "Vendas por filial" sem que joão (admin) ou qualquer viewer percebam uma linha de diferença, até que ela decida soltar a próxima versão. Essa separação existe porque um painel em produção tem leitores dependendo dele — ninguém quer abrir o relatório da segunda-feira e ver um gráfico pela metade porque alguém esqueceu uma aba aberta no editor.

Na prática, o fluxo mora em duas telas. O editor (/dashboards/[id]) é onde o rascunho vive; o cabeçalho do painel, em modo de edição, tem o botão Publicar — e é só clicando nele que o rascunho se torna a versão que todo mundo vê. Antes de confirmar, o produto mostra o diff de pendências: a lista do que vai mudar para os leitores (um widget novo, um filtro removido, uma cor de tema diferente). É a sua última chance de revisar antes de expor. Depois de publicar, a página /dashboards/[id]/versoes guarda o histórico — até 20 versões, cada uma até 512KB, com diff por widget em relação à anterior — e cada linha do histórico tem um botão Restaurar. Restaurar não é "desfazer": é publicar de novo o conteúdo daquela versão antiga, criando uma nova entrada no topo do histórico (a trilha nunca é reescrita, só cresce).

Exemplo Aurora. Maria publica a v1 de "Vendas por filial" com três KPIs (receita, pedidos, ticket médio). Durante a semana ela edita o rascunho para acrescentar uma tabela de detalhe por filial — mas ninguém no workspace vê essa tabela ainda, porque ela está só no rascunho. Quando revisa o diff de pendências antes de publicar a v2, o resumo mostra "+1 tabela, 0 removidos". Ela publica. Dois dias depois, um analista relata que a tabela nova está confundindo a diretoria (os números de detalhe não combinam com o resumo que a diretoria já conhece). Maria abre /dashboards/[id]/versoes, localiza a v1 e clica Restaurar — a diretoria volta a ver exatamente os três KPIs, e a v2 problemática fica registrada no histórico para quem quiser investigar depois.

Erros comuns. O mais frequente é achar que editar já é publicar — alguém monta um painel inteiro no rascunho, fecha a aba satisfeito, e só na segunda-feira descobre que os leitores ainda estavam vendo a versão antiga porque ninguém clicou em Publicar. O segundo é represar mudanças demais num rascunho só: quanto mais widgets você altera entre uma publicação e outra, mais difícil fica ler o diff de pendências e identificar o que realmente mudou — prefira publicar em passos pequenos. O terceiro é esquecer do teto de histórico: com 20 versões guardadas e poda automática das mais antigas, uma versão que você queria preservar como "referência" pode sair da lista se o painel for republicado com muita frequência; se precisa de um retrato permanente, isso é assunto da Aula 7 (exportar o projeto) ou da Aula 2 (um snapshot /r), não do histórico de versões.

Estado do produto. A lógica de rascunho × publicado, o diff de pendências e o histórico com restauração são GA-candidato — cobertos por suíte de testes determinística, com resultado idêntico a cada execução. Mas o teto atual de toda a plataforma é Preview: não há certificação de nuvem nem SLA sobre a operação de publicar em produção, e a renderização final do canvas (como cada widget realmente aparece na tela do leitor) não tem teste visual automatizado — é "NÃO MEDIDO" na linguagem da matriz de estados. Na prática isso significa: confie no motor (ele é testado e determinístico), mas sempre dê uma olhada na versão publicada depois de confirmar, em vez de assumir que "publicou" é sinônimo de "está perfeito na tela".

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /dashboards no console):

1. Abra o painel "Vendas por filial" (ou outro painel de treino) em modo de edição.
2. Confirme que ele ainda não tem nenhuma versão publicada, ou publique uma primeira vez para ter um ponto de partida (v1).
3. No rascunho, adicione um visual novo (por exemplo, um KPI de "Pedidos") sem clicar em Publicar.
4. Abra o painel em outra aba, em modo de consulta — confirme que o visual novo não aparece lá (os leitores ainda veem a versão congelada).
5. Volte ao editor, clique em Publicar, revise o diff de pendências e confirme a publicação (v2).
6. Confirme na aba de consulta que o visual novo agora aparece.
7. Abra /dashboards/[id]/versoes, localize a v1 no histórico e clique Restaurar.
8. Confirme que o painel voltou ao estado da v1, e que uma nova versão (não uma reescrita da v1) apareceu no topo do histórico.

Você terminou quando tiver passado por pelo menos um ciclo completo de editar → publicar → restaurar, e conseguir explicar por que o leitor nunca viu o visual novo antes do passo 5.

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#

• bi/tutorial-publicar-e-compartilhar
• bi/editor-canvas-paginas-temas

Capacidades ensinadas#

(conceitual — sem capacidade específica da matriz) — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".