As configurações de versão são específicas por projeto. Abra Lançamentos, selecione Configurações de versão, e escolha o projeto. Existem quatro 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.
- Controle de versão
- Qual é esta versão? De onde vêm as versões, o que o build recebe e onde o Coroid verifica o que está em execução.
Apenas Proprietários e Administradores podem alterar as configurações de versão. Todas as outras pessoas só podem visualizá-las. Conecte um repositório primeiro, pois toda versão aponta para um commit nele.
Ambientes
Para onde uma versão é enviada e em que ordem?
Cada projeto começa com Produção. Adicione os outros destinos de deploy, como Staging ou QA, com Adicionar ambiente. Dê um nome a cada um. O Coroid sugere uma chave baseada no nome, por exemplo staging. O seu CI/CD usa essa chave ao relatar um deployment, portanto mantenha-a estável assim que os pipelines começarem a usá-la.
Defina a ordem com Vem depois de. Um Staging que vem depois de nada e uma Produção que vem depois do Staging formam o caminho Staging › Produção. A página de versão exibe sua trilha de implantação nessa ordem, e as regras de aprovação podem exigir que o estágio anterior seja concluído com sucesso antes.
Regras de aprovação
O que deve 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 ter regras mais flexíveis e a Produção regras mais rígidas.
- Aprovações necessárias: quantas pessoas diferentes precisam aprovar. Zero permite que a versão seja implantada assim que as 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 aprovar, e quem edita as notas da versão não pode aprovar essas notas.
- Verificações de qualidade aprovadas: sempre ativado. O Gráfico de Qualidade do projeto com um
release_validationgatilho é 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 precede este.
- Notas da versão aprovadas: as notas atuais precisam de aprovação, e qualquer edição posterior requer uma nova aprovação.
- 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 o motivo e um prazo de até 24 horas; a exceção vale apenas para esse commit e ambiente.
- Regras de hotfix: regras mais flexíveis para correções urgentes: a quantidade de aprovações e se as regras de ambiente anterior e aprovação de 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 processo solicita nova aprovação. Um ambiente sem regras publicadas não pode passar nas verificações, e a tela indica isso.
Pipeline de deploy
Quem inicia um deployment e como o Coroid sabe o que aconteceu?
Selecione o ambiente na parte superior e, em seguida, escolha como os deployments são iniciados:
- Meu pipeline faz o deploy automaticamente: 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 deploy. 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 implantaçãoCrie um token de relatório para o ambiente e armazene-o como um segredo no seu CI/CD. O Coroid exibe o token uma única vez e mantém apenas um hash dele. A substituição do token interrompe imediatamente o uso do antigo. A mesma tela mostra o endpoint, o ID do projeto e a chave do ambiente necessários para o seu pipeline, além de indicar se os relatórios estão sendo recebidos. Eventos de implantação e configuração de CI Contém o formato de evento e exemplos.
Controle de versão
Qual é a versão desta release e como o build a obtém?
Escolha a origem da versão de cada release: o Coroid sugere a próxima versão, o Coroid lê a informação de um arquivo no repositório ou o próprio pipeline a informa. Cada release também recebe um número de build que só aumenta. A tela lista os valores que o Coroid passa para o seu pipeline, permite abrir um Novo trabalho para solicitar a inclusão desses valores no build e aceita uma URL de versão por ambiente para que o Coroid confirme qual versão está em execução em cada um. Incluir a versão no seu build contém os detalhes e instruções para compilações web, de servidor, Docker, iOS e Android.
Transferir configurações entre organizações
A exportação e importação de configurações incluem ambientes, sua ordem, configuração de pipeline, controle de versão, URLs de versão e regras publicadas, inclusive regras de hotfix. Tokens de relatório e números de build nunca são exportados. Crie novos tokens após uma importação; cada projeto mantém seus próprios números de build.