versionamento¶
todo workflow tem um histórico de versões — um retrato do estado dele (nome, agendamento, nós e conexões) em cada ponto em que foi salvo. isso existe para uma razão prática: dar segurança para editar um workflow em produção sem medo de quebrar algo sem volta.
como uma versão é criada¶
- salvar o workflow (o botão explícito de salvar, não o autosave de rascunho) cria uma nova versão — um snapshot do estado anterior à mudança que está sendo aplicada. ou seja, cada versão representa "como o workflow estava antes desta edição".
- o autosave que roda enquanto você edita no builder não cria versão — ele só evita perda de trabalho em andamento. só o salvamento explícito gera um ponto de restauração.
consultando o histórico¶
na tela do workflow, acesse versões para ver a lista completa, da mais recente para a mais antiga, com número de versão e quem salvou cada uma.
revertendo para uma versão anterior¶
- abra o histórico de versões do workflow.
- escolha a versão desejada e clique em reverter.
- a datablixt aplica os nós, conexões, nome e agendamento daquela versão ao workflow atual.
reverter também é seguro
antes de aplicar a versão escolhida, a datablixt tira um novo snapshot do estado atual — então reverter nunca é destrutivo. se o rollback não for o que você esperava, dá para voltar de novo.
por que isso importa¶
times que editam workflows em produção com frequência precisam de uma rede de segurança equivalente à de controle de versão de código: a possibilidade de testar uma mudança, perceber que não era a decisão certa e voltar exatamente ao estado anterior, sem reconstruir nada manualmente.
próximos passos¶
- criando um workflow
- branches de ambiente — a outra camada de segurança, separando o workflow em teste do que roda em produção