Releases
Um release é o pacote do que você vai colocar no ar. Ele junta uma versão (ex.: v2.4.0), um
nome, um destino de deploy e — o mais importante — as tarefas que entram naquela entrega. Em vez
de "achar" que está tudo pronto, o release mostra, num lugar só, o que falta fechar, quem precisa
aprovar e como voltar atrás se der ruim.
Pense nele como a ponte entre o seu board e a produção: as tarefas vão fechando, a barra de prontidão enche sozinha, e quando tudo está verde você aprova e dispara o deploy — com o histórico inteiro guardado.
No menu lateral, em Releases (G R). Também aparecem no Painel, no card Releases ativas, e
dentro de cada projeto, na aba Deploys. A lista principal agrupa os releases por projeto.
O que é um release
Cada release carrega:
- Versão — o identificador curto, em mono (ex.:
v2.4.0,v3.1.0). - Nome — o que essa entrega faz, em uma linha (ex.: "PKCE + login rate limiting").
- Destino de deploy — para onde vai (ex.:
staging · api-stg.acme.com,production · acme.com). - Pacote de tarefas — as tarefas vinculadas, com status ao vivo de cada uma.
- Aprovadores — quem assina antes do deploy.
- Riscos & stakeholders — o que pode dar errado e quem precisa ser avisado.
- Plano de rollback — escrito antes, não no calor do incidente.
Versão e nome são editáveis no lugar: clique neles no topo do release para renomear.
Criar um release
- Menu lateral → Releases → Novo release (botão no topo).
- Escolha o projeto.
- Dê a versão (ex.:
v0.1.0) e um nome descritivo. - Confirme. O release nasce em Planning e abre direto na página dele.
O destino de deploy começa apontando para o staging do projeto; você ajusta depois na lateral do release, em Deploy target.
Vincular tarefas
O pacote é o coração do release. Na página do release, seção Tarefas no pacote:
- Clique em Adicionar tarefa → busque por título ou
#id→ selecione. - Só aparecem tarefas do mesmo projeto do release.
- Cada linha mostra o status (círculo vazio ou ✓ verde), a branch, o CI e os responsáveis.
- Clique numa tarefa para abrir o detalhe dela; use o × para tirar do pacote.
Assim você enxerga, de uma vez, tudo que vai junto naquela entrega — e o que ainda está aberto.
Prontidão e auto-avanço
O release acompanha as tarefas sozinho. Conforme elas fecham, a barra de prontidão enche e o
contador done/total sobe. Quando tudo fecha, a barra fica verde e aparece "Pacote fechado".
O ciclo caminha por estes estágios:
Planning → Em revisão → Aprovada → Deploying → Em produção (ou Revertida).
O avanço é guiado pelo estado real, não por cliques soltos:
- Mandar para aprovação (botão Enviar para aprovação, quando o release está em Planning): só funciona se não houver tarefa aberta no pacote. Se houver, um aviso diz quantas faltam e a mudança é barrada.
- Sem aprovadores? O release pula a fila e vai direto para Aprovada — não fica preso em revisão para sempre.
- Com aprovadores: cada um dá seu sign-off. Quando todos aprovam, o release avança automaticamente para Aprovada.
- Deploy só fica disponível quando o status é Aprovada.
- Ao disparar, o release passa para Deploying e, ao concluir, avança sozinho para Em produção.
Um risco marcado como alto e sem mitigação bloqueia o sign-off: ninguém aprova até você escrever a mitigação ou rebaixar o risco. Registre riscos e mitigações na seção Riscos.
Aprovar, deployar e reverter
Aprovar — na lateral, o card Aprovação lista cada aprovador com seu estado (pendente, aprovado, rejeitado). Se você for um deles e o release estiver em revisão, aparece Seu sign-off com Aprovar / Rejeitar.
Deployar — botão Iniciar deploy. Antes de confirmar, um checklist pré-deploy te mostra o que conferir: todas as tarefas concluídas; todas as aprovações dadas; plano de rollback preenchido; stakeholders notificados. Os itens já satisfeitos vêm marcados; os demais você confirma na mão antes de soltar o deploy.
Reverter — enquanto está em Deploying ou Em produção, o botão Rollback fica disponível. Ele pede um motivo (e mostra seu plano de rollback, se houver). O release passa a Revertida e o motivo fica registrado na linha do tempo.
Tudo isso vira histórico: a seção Atividade monta uma timeline com criação, tarefas adicionadas, envio para aprovação, cada sign-off, o deploy e um eventual rollback.
Relação com CI e deploys
Releases conversam direto com o que você já vê nas tarefas:
- Cada tarefa do pacote exibe branch e status de CI — o mesmo que aparece no detalhe dela.
- Uma tarefa não fecha com o CI falhando (o guard de Concluída). Como o release só fica pronto quando as tarefas fecham, o CI vermelho segura a entrega de forma natural.
- O destino de deploy registra para onde a versão vai (staging ou produção).
- No projeto, a aba Deploys lista as versões com ambiente, autor e resultado.
Para ligar tarefa ↔ branch e entender o status de CI, veja GitHub & CI.
Exemplo: da branch ao deploy
Um fluxo típico de ponta a ponta:
- Abra o release cedo. Crie
v2.4.0 — PKCE + login rate limitingno projeto, ainda em Planning. - Monte o pacote. Adicione as tarefas da entrega; cada uma já tem sua branch (ex.:
feat/auth-pkce) e CI. - Trabalhe normalmente. O time abre PRs, o CI roda, as tarefas vão para Revisão e Concluída. A barra de prontidão do release sobe a cada tarefa fechada.
- Pacote fechado. Com 0 tarefas abertas, clique Enviar para aprovação.
- Sign-off. Os aprovadores assinam; ao último ✓, o release vira Aprovada.
- Deploy. Rode o checklist pré-deploy e confirme. O release entra em Deploying e, ao terminar, Em produção.
- Deu ruim? Use Rollback com o motivo; o plano que você escreveu antes está ali, e o release passa a Revertida.
Abrir o release no início do trabalho transforma "será que está pronto?" em uma barra que enche sozinha. Quando ela fecha, você só aprova e dispara — sem caça às tarefas soltas.