Documentação

Configurações de release

Configure os ambientes pelos quais uma versão passa, as regras de cada um e como os deployments são iniciados e relatados.

As configurações de versão ficam junto com o restante das configurações do projeto. Abra o projeto, selecione Configurações, e expanda Lançamentos. Existem três telas, e cada uma responde a uma pergunta.

Ambientes
Para onde um release vai? Adicione paradas e organize-as em ordem.
Regras de aprovação
O que deve estar verdadeiro antes? Aprovações, perfis, lista de verificação e regras de hotfix por ambiente.
Pipeline de implantação
Quem implanta e como o Coroid recebe o retorno? Seu pipeline ou o Coroid inicia a implantação; um token de relatório permite que o CI/CD confirme o resultado.
Configurações do projeto → Releases contém três telas, cada uma com uma pergunta.

Apenas Proprietários e Administradores podem alterar as configurações de versão. Todas as outras pessoas podem lê-las. Primeiro, conecte um repositório, pois toda versão aponta para um commit nele.

Ambientes

Para onde vai uma versão e em que ordem?

Todo projeto começa com Produção. Adicione as outras etapas de deployment, como Staging ou QA, com Adicionar um ambiente. Dê um nome a cada um. O Coroid sugere uma chave a partir do nome, por exemplo staging. O seu CI/CD usa essa chave quando relata um deployment, portanto mantenha-a estável assim que as pipelines a utilizarem.

Defina a ordem com Vem depois de. Um ambiente Staging que vem depois de nada e Produção que vem depois do Staging formam o caminho Staging › Produção. A página de versão mostra sua trilha de implantação nessa ordem, e as regras de aprovação podem exigir que a etapa anterior seja concluída com sucesso primeiro.

Regras de aprovação

O que precisa ser verdadeiro antes que uma versão seja implantada aqui?

Selecione o ambiente na parte superior. As regras são específicas por ambiente, então o Staging pode ser menos rigoroso e a Produção mais estrita.

  • Aprovações necessárias: quantas pessoas diferentes precisam aprovar. Zero permite que uma versão seja implantada assim que suas verificações forem aprovadas.
  • Quem pode aprovar: as funções da organização autorizadas a aprovar.
  • Manter solicitante e aprovadores separados: a pessoa que inicia o deployment não pode também aprova-lo, e quem edita as notas da versão não pode aprova-las.
  • Verificações de qualidade aprovadas: sempre ativado. O Gráfico de Qualidade do projeto com um release_validation gatilho é executado contra o commit exato. Publique esse gráfico nas configurações de qualidade do projeto.
  • Ambiente anterior primeiro: a versão já deve estar implantada no ambiente que este vem depois.
  • Notas da versão aprovadas: as notas atuais precisam de aprovação, e qualquer edição posterior precisa de uma nova.
  • Lista de verificação: etapas manuais que alguém confirma na página de versão, como "Migração de banco de dados revisada". Marque um item como obrigatório ou opcional. Um item obrigatório pode permitir uma exceção temporária. Um Proprietário ou Administrador registra um motivo e um prazo de até 24 horas; a exceção vale apenas para aquele commit e ambiente.
  • Regras de hotfix: regras mais flexíveis para correções urgentes: a quantidade de aprovações e se a aprovação do ambiente anterior e das notas ainda se aplicam. As verificações de qualidade e os itens obrigatórios da lista de verificação sempre são aplicados, e apenas Proprietários e Administradores aprovam hotfixes.

Selecione Publicar regras para salvar. A publicação cria uma nova versão das regras. As aprovações concedidas na versão antiga ficam desatualizadas, portanto uma versão em execução solicita aprovação novamente. Um ambiente sem regras publicadas não pode passar em suas verificações, e a tela indica isso.

Pipeline de deployment

Quem inicia um deployment e como o Coroid sabe o que aconteceu?

Selecione o ambiente na parte superior e depois escolha como os deployments são iniciados:

  • Meu pipeline faz o deployment sozinho: mantenha seu processo atual. O Coroid registra os deployments quando o seu CI/CD os relata, ou quando um Proprietário ou Administrador registra um deployment externo na página de versão.
  • O Coroid inicia um fluxo de trabalho do GitHub Actions ou O Coroid inicia um pipeline do GitLab CI/CD: exibido quando o repositório do projeto está nesse provedor. Insira o branch ou tag que aponta para o commit da versão, o arquivo de fluxo de trabalho para o GitHub e o nome exato da tarefa que faz o deployment. O Coroid verifica a referência antes de iniciar a execução e verifica a tarefa nomeada antes de aceitar o sucesso.

Em Relatórios de deployment, crie um token de relatório para o ambiente e armazene-o como segredo no seu CI/CD. O Coroid mostra o token uma vez e guarda apenas um hash dele. Substituir o token interrompe imediatamente o antigo. A mesma tela exibe o endpoint, o ID do projeto e a chave do ambiente que seu pipeline precisa, além de informar se os relatórios estão chegando. Eventos de deployment e configuração de CI tem o formato de evento e exemplos.

Movendo configurações entre organizações

A exportação e importação de configurações incluem ambientes, sua ordem, configuração de pipeline e regras publicadas, inclusive regras de hotfix. Os tokens de relatório nunca são exportados. Crie novos após uma importação.