Lançamentos

A plataforma transforma tarefas e planos em pull requests revisados. Depois que são mesclados, um pull request de release responde à próxima pergunta: qual parte desse trabalho está em execução onde e se foi seguro colocá-la lá?

Uma release fixa um commit exato do Git e o acompanha pelos seus ambientes, como Staging e depois Produção. O commit pode já estar no seu ramo de implantação, ou Coroid pode primeiro agrupar pull requests abertos em um pull request de release cujo commit de merge se torna a release. Em cada etapa, Coroid verifica o commit, coleta as aprovações que você solicitar e registra a implantação que seu CI/CD reporta. Coroid nunca marca uma release como implantada por conta própria. Seu pipeline, ou alguém que registre uma implantação externa, precisa confirmá-la.

A ideia em um minuto#

• Release: um commit, um nome e uma versão opcional. Uma versão como 2.4.0 é opcional, então a entrega contínua funciona sem tags.
• Ambiente: uma parada no caminho até seus usuários, como Staging ou Produção. Cada projeto define suas próprias paradas e sua ordem.
• Rollout: quais ambientes o release já alcançou até o momento.
• Trabalho: as tarefas planejadas para o release e as alterações mescladas que ele contém, exibidas como concluído de total.
• Quatro etapas por ambiente: Verificações, aprovação, Implantar e integridade. A página do release sempre abre na etapa que requer sua intervenção.
• Agrupamento: um release criado a partir de pull requests abertos. Coroid os mescla em um ramo de release, em uma ordem que você pode alterar, e abre um pull request de release. Um release agrupado tem uma quinta etapa, Agrupamento, antes das Verificações.

Leia um release num piscar de olhos#

Abra Lançamentos na barra lateral principal de cada projeto, ou a guia Lançamentos desse projeto. Em execução agora, no topo, mostra a versão que cada ambiente executa, a partir de sua última implantação confirmada, e quem a iniciou. A lista exibe o progresso do trabalho do release, seu rollout entre ambientes e seu status. Use as guias para alternar entre releases em andamento, já enviados ou fechados.

Selecione um release para abrir sua página.

O rastreador de rollout também funciona como um seletor. Selecione um ambiente nele para ver as quatro etapas desse ambiente. A página abre no primeiro ambiente que o release ainda não alcançou, então a próxima ação geralmente já está visível.

As quatro etapas em cada ambiente#

Verificações. Escolha Executar verificações. Coroid executa o Gráfico de Qualidade de validação de release do projeto contra o commit exato e confirma que todas as alterações vinculadas estão dentro desse commit. Todos os itens de checklist exigidos para o ambiente também devem ser marcados como concluídos. Se algo bloquear o release, a etapa indicará o motivo. Alterar o commit ou as alterações vinculadas torna as verificações anteriores desatualizadas, e a etapa pedirá que você as execute novamente.

Aprovação. Depois que as Verificações forem aprovadas, as pessoas permitidas pelas suas regras podem aprovar. A etapa mostra quantas aprovações são necessárias e de quais funções. Se suas regras exigirem notas de release aprovadas, elas também são aprovadas aqui.

Implantar. Quando as Verificações e a aprovação estiverem concluídas, o release estará pronto para o ambiente. Se Coroid estiver conectado ao GitHub Actions ou ao GitLab CI/CD para esse ambiente, um Proprietário ou Administrador escolherá Implantar em… e Coroid iniciará a pipeline para esse commit exato. Caso contrário, sua pipeline implantará por conta própria e informará o resultado. De qualquer forma, a etapa só ficará verde quando o sucesso for confirmado.

Integridade. Após uma implantação bem-sucedida, Coroid executará o Gráfico de Qualidade canary do projeto, se houver um. Um canary aprovado marca o ambiente como saudável. Um canary reprovado mostra Requer atenção e oferece recuperação. Sem um canary, a integridade permanece desconhecida em vez de ser considerada saudável por suposição.

O que os status significam#

Pronto Um pull request de release nunca significa que o código foi implantado. Somente uma implantação confirmada faz o release avançar na trilha de lançamento.

Fluxos de trabalho#

Configurar releases para um projeto#

Faça isso uma vez por projeto. Abra Lançamentos, selecione Configurações de release, e escolha o projeto.

1. Em Ambientes, adicione suas etapas e organize-as, por exemplo, Staging antes de Produção.

2. Em Regras de aprovação, publique regras para cada ambiente: quantas aprovações são necessárias, de quais funções e quais itens de checklist. Um ambiente não pode passar nas verificações até que as regras sejam publicadas.

3. Em Pipeline de implantação, escolha se Coroid iniciará as implantações ou se sua pipeline fará isso. Depois, crie um token de relatório para que seu CI/CD possa informar ao Coroid o que foi implantado.

4. Em Controle de versão, escolha de onde vem a versão de cada release e dê a cada ambiente uma URL de versão para que Coroid possa confirmar o que está em execução lá.

Configurações de release orienta você por cada tela, e Coloque a versão no seu build mostra como a versão chega ao seu aplicativo.

Entregar o trabalho planejado#

Use isso quando souber com antecedência o que deve ser lançado junto.

1. Crie o release com antecedência, antes que um commit seja fixado. Ele começa como rascunho.
2. Defina o release de destino nas tarefas que deseja incluir nele. Elas aparecem em Tarefas planejadas, e a barra de trabalho será preenchida à medida que elas forem concluídas.
3. Quando o trabalho for mesclado, selecione Editar detalhes e escolha o commit a serem enviados. Coroid confirma quais alterações mescladas o commit contém.
4. Siga os quatro passos para seu primeiro ambiente e depois para o próximo.

Agrupar pull requests abertos#

Use isso quando muitos pull requests estiverem aguardando, tanto do Coroid quanto da sua equipe, e precisarem ser lançados juntos.

1. Selecione Novo release, escolha o projeto e selecione Pull requests abertos. Essa opção requer um repositório GitHub ou GitLab, então os projetos hospedados pelo Coroid lançam um commit.
2. Coroid lista os pull requests abertos na branch de implantação, começando pelos mais seguros. Um pull request aberto pelo Coroid aparece como sua tarefa ou plano. Coroid avalia o que o provedor e sua própria revisão já sabem: verificações, revisões, tamanho, conflitos e arquivos que vários pull requests tocam. Ele exclui rascunhos, verificações com falha, alterações solicitadas e pull requests de forks, e explica o motivo.
3. Desmarque o que deve esperar e use as setas para alterar a ordem. Um pull request que depende de outro (um pull request empilhado ou um que indique "depende de #12") sempre vem depois dele.
4. Selecione Criar release. Coroid cria release/<version> a partir da branch de implantação, mescla os pull requests em ordem e abre um pull request de release que lista e vincula cada um deles.
5. Se houver um conflito entre pull request e a branch de release, o Agrupamento passo para ali e exibe os arquivos. Selecione Resolver com Coroid para permitir que o agente desenvolvedor faça a mesclagem e resolva o conflito em uma tarefa, ou Deixar de fora para continuar sem ele.
6. Reveja o pull request de release e mescle-o com um commit de mesclagem. Seu provedor então marca todos os pull request agrupados como mesclados. Coroid fixa o commit de mesclagem como commit de release, registra os pull requests agrupados como o que foi lançado e fecha os que ainda estiverem abertos com um link para o pull request de release.
7. Siga os quatro passos para cada ambiente, como de costume.

Mesclagens tipo squash ou rebase também funcionam, mas os pull requests originais não são marcados como mesclados pelo seu provedor. Coroid os fecha com um comentário.

Lançar o que está na branch principal#

Use isso para entrega contínua, quando você lança tudo o que foi mesclado.

1. Selecione Novo release e escolha o commit, geralmente o mais recente da branch de implantação.
2. Em Comparar com, selecione o ambiente que você vai substituir. Coroid lista os pull requests e commits entre o que está em execução lá e seu commit, e seleciona os que pode verificar.
3. Deixe o nome e a versão em branco, se desejar. Coroid nomeia o release com base na data e no commit curto, e a fonte de versão do projeto preenche a versão. Cada release também recebe o próximo número de build.
4. Crie o release e siga os quatro passos.

Se o seu pipeline implantar a cada merge ou alguém fizer a implantação manualmente, sem consultar o Coroid, ele ainda poderá registrar cada implantação. Quando não houver um release para um commit registrado, o Coroid criará um release observado para ele, marcado claramente como não tendo passado nas verificações do Coroid. Ele usará a versão informada pelo pipeline ou, quando o Coroid atribuir as versões do projeto, a próxima versão (1.4.1 após 1.4.0), e o próximo número de build.

Enviar uma correção urgente#

Um Proprietário ou Administrador pode ativar Esta é uma correção rápida ao criar um release, marque o commit completo da correção e explique por que o prazo normal não é viável. As correções rápidas seguem as regras específicas de cada ambiente, que podem exigir menos aprovações. As verificações de qualidade e os itens obrigatórios da lista de verificação continuam valendo, e apenas Proprietários e Administradores aprovam correções rápidas.

Recuperar-se quando algo falhar#

Se a etapa de integridade indicar Requer atenção, abra Integridade no ambiente afetado e selecione um commit estável anterior para reimplantar. Recuperação e trens de release aborda as opções disponíveis, incluindo pipelines que não conseguem enviar relatórios.

Do chat ou do seu editor#

O assistente de chat e o servidor MCP do Coroid contam com as mesmas ferramentas de release: listar e inspecionar releases, escolher um commit, visualizar o que seria enviado, preparar um release, agrupar pull requests abertos, executar suas verificações, aprová-lo, solicitar uma implantação e rascunhar notas. O agrupamento, a aprovação e a implantação sempre precisam de confirmação humana. Veja Assistente de chat e Coroid como servidor MCP.

Liberar vários projetos juntos#

Um trem de release agrupa releases de vários projetos que devem ser enviados juntos e em ordem, como o API e o aplicativo que depende dele. Veja Recuperação e trens de release.

O que o Coroid faz e o que não faz#

• O Coroid marca, verifica e registra. Seu repositório e o CI/CD compilam e implantam.
• Ao agrupar pull requests, o Coroid cria a branch de release e o pull request de release. Ele nunca faz o merge do pull request de release por você.
• O Coroid inicia um pipeline somente quando você o conecta e um Proprietário ou Administrador solicita uma implantação.
• Uma solicitação de implantação não é prova suficiente. A trilha de lançamento só avança quando seu pipeline confirma o sucesso ou alguém registra uma implantação externa verificada.
• As notas de release são rascunhos que você edita e aprova. O Coroid não as publica em nenhum lugar.
• Um sprint é um período de planejamento, não um limite de implantação. Um sprint pode alimentar vários releases, e um release pode conter trabalho de vários sprints.

Relacionado#

• Configurações de release
• Eventos de implantação e configuração de CI
• Inclua a versão na sua compilação
• Recuperação e trens de release
• Sprints
• Tarefas, planos, sprints e faixas
• Qualidade e evidências de revisão