Lançamentos

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

Uma release fixa um commit específico do Git e o acompanha por todos os ambientes, como Staging e Produção. Esse commit pode já estar no seu branch de deploy ou o Coroid pode primeiro agrupar pull requests abertos em um pull request de release, cujo commit de merge se tornará a release. Em cada etapa, o Coroid verifica o commit, coleta as aprovações solicitadas por você e registra o deploy informado pelo seu CI/CD. O Coroid nunca marca uma release como implantada com base apenas em sua própria avaliação. Sua pipeline ou uma pessoa responsável por registrar o deploy externo precisa confirmar essa implantação.

A ideia em um minuto#

• Lançamento: um commit, um nome e uma versão opcional. Uma versão como 2.4.0 é opcional, para que a entrega contínua funcione sem tags.
• Ambiente: uma parada no caminho até seus usuários, como Staging ou Produção. Cada projeto define suas próprias paradas e ordem.
• Rollout: quais ambientes o lançamento já alcançou até agora.
• Trabalho: as tarefas planejadas para o lançamento e as alterações mescladas que ele contém, exibidas como concluídas de um total.
• Quatro etapas por ambiente: verificações, aprovação, implantação e integridade. A página de lançamento sempre abre na etapa que requer sua intervenção.
• Agrupamento: uma release criada a partir de pull requests abertos. O Coroid os mescla em um branch de release, na ordem que você definir, e abre um pull request de release. Uma release agrupada possui uma quinta etapa, Agrupamento, antes das verificações.

Consulte um lançamento rapidamente#

Abra Lançamentos na barra lateral principal de cada projeto, ou a guia Lançamentos desse projeto específico. A lista mostra o progresso do trabalho de cada lançamento, seu rollout entre ambientes e seu Status. Use as guias para alternar entre lançamentos em andamento, já enviados ou fechados.

Selecione um lançamento 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 lançamento ainda não alcançou, para que a próxima ação necessária já esteja visível.

As quatro etapas em cada ambiente#

Verificações. Escolha Executar verificações. O Coroid executa o Quality Graph de validação de lançamento do projeto sobre o commit específico e confirma que todas as alterações vinculadas estão dentro desse commit. Os itens de checklist exigidos para o ambiente também devem estar marcados como concluídos. Se algo bloquear o lançamento, a etapa indicará o motivo. Alterar o commit ou as alterações vinculadas torna as verificações anteriores obsoletas, e a etapa pedirá que você as execute novamente.

Aprovação. Após a aprovação das verificações, as pessoas permitidas pelas suas regras podem aprovar. A etapa mostra quantas aprovações são necessárias e de quais perfis. Se suas regras exigirem notas de lançamento aprovadas, elas também são aprovadas aqui.

Implantação. Quando as verificações e a aprovação estiverem concluídas, o lançamento estará pronto para o ambiente. Se o Coroid estiver conectado ao GitHub Actions ou ao GitLab CI/CD desse ambiente, um Proprietário ou Administrador selecionará Implantar em… e o Coroid iniciará a pipeline para esse commit específico. Caso contrário, sua pipeline realiza a implantação por conta própria e reporta o resultado. De qualquer forma, a etapa só fica verde quando o sucesso é confirmado.

Integridade. Após uma implantação bem-sucedida, o Coroid executa o Quality Graph canary do projeto, se houver. Um canary aprovado indica que o ambiente está íntegro. Um canary reprovado exibe Requer atenção e oferece opções de recuperação. Sem um canary, a integridade permanece desconhecida em vez de ser considerada íntegra por pressuposição.

O que significam os Status#

Pronto Nunca significa que foi implantado. Somente uma implantação confirmada faz o lançamento avançar na trilha de distribuição.

Fluxos de trabalho#

Configure lançamentos para um projeto#

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

1. Em Ambientes, adicione suas etapas e defina a ordem delas, 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 perfis e quais itens de lista de verificação. 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 Versionamento, escolha de onde virá a versão de cada lançamento e atribua a cada ambiente uma URL de versão para que Coroid possa confirmar o que está em execução lá.

Configurações de lançamento Guias você por cada tela, e Inclua a versão na sua compilação 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 lançamento com antecedência, antes que um commit seja definido. Ele começa como rascunho.
2. Defina o lançamento 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 para entregar. O Coroid confirma quais alterações mescladas o commit contém.
4. Siga os quatro passos para seu primeiro ambiente, 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 lançamento, escolha o projeto e selecione Pull requests abertos. A opção requer um repositório GitHub ou GitLab, portanto, projetos hospedados pelo Coroid lançam um commit.
2. O 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. O 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, explicando 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 lançamento. O Coroid cria release/<version> do branch de deploy, mescla os pull requests na ordem correta e abre um pull request de release que lista e vincula cada um deles.
5. Se um pull request entrar em conflito com o branch de release, o Agrupamento passo interrompe nesse ponto e exibe os arquivos. Selecione Resolver com Coroid para permitir que o agente de desenvolvimento faça o merge e resolva o conflito em uma tarefa, ou Deixar de lado para continuar sem ele.
6. Revise o pull request de release e mescle-o com um commit de merge. Em seguida, seu provedor marca todos os pull request agrupados como mesclados. O Coroid fixa o commit de merge como o commit da release, registra os pull requests agrupados como parte do produto final e fecha aqueles que ainda estiverem abertos, com um link para o pull request de release.
7. Siga os quatro passos para cada ambiente, como de costume.

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

Entregar o que está no branch principal#

Use isso para entrega contínua, quando desejar entregar tudo o que foi mesclado.

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

Se sua pipeline implantar a cada mesclagem sem consultar o Coroid, ainda poderá relatar cada implantação. Quando nenhum lançamento existir para um commit relatado, o Coroid criará um lançamento observado para ele, marcado claramente como não tendo passado nas verificações do Coroid.

Entregar uma correção urgente#

Um Proprietário ou Administrador pode ativar Esta é uma correção rápida ao criar um lançamento, defina o commit completo da correção e explique por que o prazo normal não funciona. As correções rápidas seguem as regras de correção rápida de cada ambiente, que podem exigir menos aprovações. As verificações de qualidade e os itens de lista de verificação obrigatórios ainda se aplicam, e apenas Proprietários e Administradores aprovam correções rápidas.

Recuperar-se quando algo falhar#

Se a etapa de integridade mostrar Requer atenção, abra Integridade no ambiente afetado e escolha um commit estável anterior para fazer o novo deploy. Recuperação e trens de release abrange as opções, incluindo pipelines que não conseguem gerar relatórios.

Do Chat ou do seu editor#

O assistente de chat e o servidor MCP do Coroid têm as mesmas ferramentas de release: listar e inspecionar releases, escolher um commit, visualizar o que seria lançado, preparar um release, agrupar pull requests abertos, executar suas verificações, aprová-lo, solicitar uma implantação e rascunhar notas. Agrupar, aprovar e implantar sempre precisam de confirmação humana. Veja Assistente de chat e Coroid como servidor MCP.

Liberar vários projetos em conjunto#

Um trem de release agrupa releases de diversos projetos que precisam ser entregues juntos e em ordem, como um 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 define, verifica e registra. Seu repositório e o CI/CD compilam e implantam.
• Ao agrupar pull requests, o Coroid cria o branch de release e o pull request de release. Ele nunca mescla o pull request de release para você.
• O Coroid inicia um pipeline somente quando você conecta um e um Proprietário ou Administrador solicita uma implantação.
• Uma solicitação de implantação não é prova. A trilha de rollout só avança quando seu pipeline confirma 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 lugar nenhum.
• 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 deploy e configuração de CI
• Inclua a versão na sua compilação
• Recuperação e trens de release
• Sprints
• Tarefas, planos, Sprints e fluxos
• Evidências de qualidade e revisão