deployments

um pipeline nasce em developer e só chega à produção (main) através de um deployment deliberado. a datablixt oferece dois caminhos para isso, dependendo do quanto de processo formal a sua organização já usa.

deploy direto (publicação local)

o caminho mais simples: com um clique, a versão atual do pipeline em developer é exportada e publicada diretamente como o pipeline de produção correspondente.

1. abra o pipeline na branch developer e clique em publicar.
2. adicione uma nota descrevendo o que mudou (opcional, mas recomendado para auditoria).
3. confirme. a datablixt registra o deployment com status deployed e aponta para o pipeline de produção criado ou atualizado.

esse caminho é adequado para times pequenos ou pipelines de baixo risco, onde o ciclo de revisão formal não compensa o atrito.

deploy via github (revisão em pull request)

para organizações que já usam GitHub como fonte de verdade e querem uma revisão formal antes de ir para produção, é possível conectar um repositório: cada publicação abre um pull request com o snapshot do workflow, em vez de aplicar a mudança diretamente.

1. conecte a organização a uma instalação do GitHub (uma vez, pelo administrador da conta).
2. associe o pipeline em developer a um repositório e branch base.
3. ao publicar, a datablixt abre um PR com as mudanças. o deployment fica com status pending até o PR ser mesclado.
4. quando o PR é mesclado, a datablixt detecta o merge e aplica o pipeline em produção automaticamente — o status avança para merged e depois deployed.

esse caminho existe para times que já têm um processo de revisão de código e querem que mudanças de pipeline passem pelo mesmo crivo.

histórico de deployments

toda publicação — por qualquer um dos dois caminhos — fica registrada com origem, destino, quem publicou, quando e o status final (pending, merged, deployed ou failed). isso funciona como uma trilha de auditoria: em caso de incidente em produção, é possível ver exatamente qual deployment introduziu a mudança.

próximos passos

• branches de ambiente
• releases — quando dois ambientes (developer/main) não são suficientes e você precisa de estágios intermediários com aprovação