Pular para conteúdo

releases

branches e deployments resolvem bem o cenário de dois ambientes: developer e main. mas organizações maiores costumam precisar de mais estágios — por exemplo, desenvolvimento → homologação → produção — com aprovação formal antes de avançar para o próximo. é para isso que existem as releases.

o conceito

uma release pipeline é uma sequência de estágios que você define uma vez (ex: DEV → HOMOLOG → PROD), cada um associado a um workspace. cada estágio pode exigir aprovação manual antes de receber uma promoção — um gate de qualidade adicional, além dos testes que já foram feitos em developer.

uma release é uma promoção concreta entre dois estágios consecutivos dessa sequência: leva um conjunto de pipelines de um estágio para o próximo.

como funciona uma promoção

  1. ao iniciar uma release entre dois estágios, a datablixt calcula automaticamente o diff: quais pipelines são novos no destino, quais já existem mas foram modificados na origem, e quais já estão em sincronia (nada a fazer).
  2. você escolhe quais pipelines da lista efetivamente entram nessa release — pipelines não selecionados são marcados como skip, e ficam de fora da promoção.
  3. se o estágio de destino exige aprovação, a release fica com status pendente de aprovação até alguém com permissão aprovar ou rejeitar.
  4. uma vez aprovada (ou se o estágio não exige aprovação), a release é executada: os pipelines selecionados são publicados no workspace do estágio de destino.
  5. a release termina como implantada (sucesso) ou falhou, com o detalhe do erro registrado.
DEV  ──release──▶  HOMOLOG  ──release (com aprovação)──▶  PROD

status de uma release

status significado
pendente de aprovação aguardando aprovação humana no estágio de destino
aprovada aprovada, aguardando execução
rejeitada rejeitada pelo aprovador — não avança
implantando em execução
implantada concluída com sucesso
falhou a promoção não foi concluída

por que isso importa

quanto mais gente e mais pipelines uma organização acumula, maior o risco de uma mudança boa em developer ser promovida direto para produção sem ninguém revisar o impacto. releases resolvem isso com um processo formal — sem exigir que você monte esse controle de aprovação na mão, com planilha e mensagens soltas.

quando usar releases em vez de um deploy direto

  • deploy direto (deployments): times pequenos, mudanças de baixo risco, dois ambientes bastam.
  • releases: organizações com múltiplos ambientes, necessidade de aprovação formal antes de produção, ou pipelines demais para promover um por um manualmente.

próximos passos