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 ambienteDê um nome para cada um. 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 uma implantação 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 implantações quando seu CI/CD as reporta, ou quando um Proprietário ou Administrador registra uma implantação externa na página de lançamento.
- 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. Informe o ramo ou tag que aponta para o commit de lançamento, o arquivo de fluxo de trabalho para o GitHub e o nome exato da tarefa que realiza a implantação. O CoRoid verifica a referência antes de iniciar a execução e confere a tarefa nomeada antes de aceitar sucesso.
Em Relatórios de implantação, crie um token de relatório para o ambiente e armazene-o como segredo no seu CI/CD. O CoRoid exibe o token uma vez e guarda apenas um hash dele. A substituição do token interrompe imediatamente o antigo. Na mesma tela, estão o endpoint, o ID do projeto e a chave do ambiente necessários para seu fluxo de trabalho, além de informar se os relatórios estão chegando. 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 lançamento: o CoRoid sugere a próxima versão, o CoRoid a lê de um arquivo no repositório ou seu fluxo de trabalho a reporta. Cada lançamento também recebe um número de compilação que só aumenta. A tela lista os valores que o CoRoid passa para seu fluxo de trabalho, pode abrir um Novo trabalho com uma solicitação para adicioná-los à sua compilação e obtém uma URL de versão por ambiente para que o CoRoid possa confirmar 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.