Aprovação de solicitações de mudança
Uma solicitação de alteração pode ser aprovada manual ou automaticamente (desde que todas as verificações de conformidade necessárias sejam aprovadas e a prontidão da implantação seja true).
Por padrão, são criadas solicitações de mudanças padrão e, em caso de aprovação de todas as verificações de conformidade necessárias, a disponibilidade de implementação é configurada como true. Quando uma solicitação de mudança é
do tipo padrão e a disponibilidade de implementação é configurada como true, ela é automaticamente aprovada.
Se uma ou mais verificações de conformidade falharem, a prontidão da implantação será definida como false, o pipeline de implantação contínua será interrompido e a implantação será interrompida devido à solicitação de alteração não
aprovada.
Você ainda pode prosseguir com a implementação em caso de emergência, adicionando um rótulo de emergência à solicitação pull de promoção.
Você também pode fornecer uma solicitação de alteração pré-aprovada manualmente que o pipeline de implantação pode utilizar (com o rótulo status_approved) no Gitlab
Adote uma das seguintes abordagens:
Opção 1: adicionar uma etiqueta de emergência ao RP de promoção
Caso seja necessário fazer a implementação imediata das mudanças de emergência, é possível usar o modo de emergência. Quando você promover uma alteração, adicione um rótulo emergency ao pull request de promoção para solicitar que
o pipeline de implantação contínua crie um pedido de alteração de emergência. As solicitações de mudanças de emergência permitem que a implementação tenha continuidade, mesmo que ainda não tenham sido aprovadas. Para obter mais informações
sobre o fluxo de emergência, consulte Automatização do gerenciamento de mudanças.
Use o modo de emergência com moderação e com cautela.
Você pode definir o valor do rótulo de emergência (default: EMERGENCY) que o pipeline de implantação contínua procura no pull request de promoção quando você cria a cadeia de ferramentas.
Também é possível alterar o valor do rótulo de emergência a partir das variáveis de ambiente do pipeline:
Esse rótulo, indicado pelo valor definido pela propriedade de ambiente emergency-label, precisa ser adicionado ao pull request de promoção para indicar ao pipeline de CD que a alteração é uma alteração de emergência.
Quando a implementação é concluída, a solicitação de alteração de emergência é definida para o estado Review, o que indica que ela exige que os aprovadores atribuídos a revisem e aprovem retroativamente.
Não há fluxo de emergência no lado do oleoduto da CI. No entanto, a definição de uma propriedade do pipeline/trigger de CI skip-inventory-update-on-failure como um valor vazio ou 0 permitirá que o repositório de inventário
seja atualizado, mesmo que os problemas sejam detectados na execução do pipeline de CI. Com esse inventário atualizado, uma mudança de emergência pode ser ativada.
Opção 2: Fornecimento de um CR pré-aprovado manualmente
Caso a implementação não seja emergencial, é possível aguardar até que a solicitação de mudança seja aprovada manualmente. Use o número de solicitação de alteração existente e pré-aprovado manualmente que está definido nas variáveis de ambiente
do pipeline de implantação contínua. O valor padrão é notAvailable, o que significa que o pipeline de implantação contínua cria uma nova solicitação de alteração.
