Definir aprovações e verificações

Serviços de DevOps do Azure

Um gasoduto é composto por etapas. Um autor de pipeline pode controlar se um estágio deve ser executado definindo condições no estágio. Outra maneira de controlar se e quando uma etapa deve ser executada é através de aprovações e verificações.

Aprovações e outras verificações não são definidas no arquivo yaml. Os usuários que modificam o arquivo yaml do pipeline não podem modificar as verificações realizadas antes do início de um estágio. Os administradores de recursos gerenciam verificações usando a interface Web do Azure Pipelines.

Os pipelines dependem de recursos como ambientes, conexões de serviço, pools de agentes, grupos de variáveis e arquivos seguros. As verificações permitem que o proprietário do recurso controle se e quando um estágio em qualquer pipeline pode consumir um recurso. Como proprietário de um recurso, você pode definir verificações que devem ser satisfeitas antes que um estágio que consuma esse recurso possa ser iniciado. Por exemplo, uma verificação de aprovação manual em um ambiente garante que a implantação nesse ambiente só aconteça depois que o usuário designado revisar as alterações que estão sendo implantadas.

Um estágio pode consistir em muitos trabalhos, e cada trabalho pode consumir vários recursos. Antes do início da execução de uma etapa, todas as verificações de todos os recursos utilizados nessa etapa devem ser satisfeitas. O Azure Pipelines pausa a execução de um pipeline antes de cada estágio e aguarda que todas as verificações pendentes sejam concluídas.

Existem cinco categorias de aprovações e verificações e elas são executadas na ordem em que foram criadas dentro de cada categoria. As verificações são reavaliadas com base no intervalo de repetição especificado em cada verificação. Se todas as verificações não forem bem-sucedidas até o tempo limite especificado, esse estágio não será executado. Se alguma das verificações falhar (por exemplo, se você rejeitar uma aprovação em um dos recursos), esse estágio não será executado.

Você pode repetir um estágio quando as aprovações e verificações expirarem.

As verificações estáticas são executadas primeiro e, em seguida, as aprovações de pré-verificação são executadas. As categorias por ordem são:

1. Verificações estáticas: Controle de ramificação, Modelo necessário e Artefato de avaliação
2. Pré-verificação de aprovações
3. Verificações dinâmicas: Aprovação, Invocar Função do Azure, Invocar API REST, Horário Comercial, Consultar alertas do Azure Monitor
4. Aprovações pós-verificação
5. Fechadura exclusiva

Você também pode ver a ordem de execução na guia Aprovações e verificações .

Importante

As verificações podem ser configuradas em ambientes, conexões de serviço, repositórios, grupos de variáveis, arquivos seguros e pools de agentes.

As conexões de serviço não podem ser especificadas por variável.

Aprovações

Você pode controlar manualmente quando um estágio deve ser executado usando aprovação e verificações. Essa verificação é comumente usada para controlar implantações em ambientes de produção.

1. Entre em sua organização do Azure DevOps e navegue até seu projeto.

2. Selecione Pipelines>Environments e, em seguida, selecione seu ambiente.

3. Selecione a guia Aprovações e verificações e, em seguida, selecione o + sinal para adicionar uma nova verificação.

   

4. Selecione Aprovações e, em seguida, selecione Avançar.

5. Adicione usuários ou grupos como seus aprovadores designados e, se desejar, forneça instruções para os aprovadores. Especifique se deseja permitir ou restringir os aprovadores de aprovar suas próprias execuções e especifique o tempo limite desejado. Se as aprovações não forem concluídas dentro do tempo limite especificado, o estágio será marcado como ignorado.

6. Selecione Criar quando terminar.

   

7. Depois que a verificação de aprovação é acionada, uma janela de prompt, como mostrado no exemplo a seguir, é apresentada na interface do usuário. Esta janela fornece a opção para os aprovadores rejeitarem ou aprovarem a execução, juntamente com quaisquer instruções que a acompanhem.

   

A lista de usuários que podem revisar uma Aprovação é fixada no momento em que as aprovações e verificações começam a ser executadas. Ou seja, as alterações na lista de usuários e grupos de uma verificação de aprovação feita depois que as verificações começam a ser executadas não são coletadas.

Nota

Se um grupo for designado como aprovador, apenas um usuário dentro do grupo precisará aprovar para que a execução prossiga.

Aprovações diferidas

Há situações em que o momento em que uma aprovação é dada e o tempo em que a implantação deve começar não coincidem. Por exemplo, talvez você queira esperar para implantar uma nova versão até um horário de baixo tráfego à noite.

Para resolver esse cenário, você pode adiar uma aprovação e definir o tempo em que a aprovação entra em vigor.

1. Selecione Adiar aprovação.

   

2. Defina o tempo de aprovação.

   

Você verá a aprovação no painel Verificações como uma pré-aprovação. A aprovação entra em vigor no momento definido.

Controlo de sucursais

Usando a verificação de controle de ramificação, você pode garantir que todos os recursos vinculados ao pipeline sejam criados a partir das ramificações permitidas e que as ramificações tenham proteção habilitada. Essa verificação ajuda a controlar a prontidão da versão e a qualidade das implantações. Caso vários recursos estejam vinculados ao pipeline, a origem de todos os recursos é verificada. Se você vinculou outro pipeline, a ramificação da execução específica que está sendo implantada é verificada quanto à proteção.

Para definir a verificação de controle de filial:

1. Em seu projeto do Azure DevOps, vá para o recurso (por exemplo, ambiente) que precisa ser protegido.

2. Navegue até Aprovações e Verificações do recurso.

3. Escolha a verificação de controle de ramificação e forneça uma lista separada por vírgulas de ramificações permitidas. Você pode exigir que a ramificação tenha a proteção habilitada. Você também pode definir o comportamento da verificação se o status de proteção de uma das ramificações não for conhecido. Uma ramificação é considerada protegida se pelo menos uma política tiver sido aplicada (incluindo políticas aplicadas no nível do repositório).

   

Em tempo de execução, a verificação validaria ramificações para todos os recursos vinculados na execução em relação à lista permitida. Se alguma das ramificações não corresponder aos critérios, a verificação falhará e o estágio será marcado como falha.

Nota

A verificação exige que os nomes das filiais sejam totalmente qualificados. Verifique se o formato do nome da ramificação é refs/heads/<branch name>

Horário de funcionamento

Caso você queira que todas as implantações em seu ambiente aconteçam apenas em uma janela de tempo específica, a verificação do horário comercial é a solução ideal. Quando você executa um pipeline, a execução do estágio que usa o recurso aguarda o horário comercial. Se você tiver várias execuções em execução simultaneamente, cada uma delas será verificada de forma independente. No início do horário comercial, o cheque é marcado como bem-sucedido para todas as corridas.

Se a execução da etapa não tiver começado no final do horário comercial (atrasada por alguma outra verificação), a aprovação do horário comercial é automaticamente retirada e uma reavaliação é agendada para o dia seguinte. A verificação falhará se a execução do estágio não começar dentro do período de tempo limite especificado para a verificação e o estágio for marcado como falha.

Invocar a função do Azure

As funções do Azure são a plataforma de computação sem servidor oferecida pelo Azure. Com as funções do Azure, você pode executar pequenos pedaços de código (chamados "funções") sem se preocupar com a infraestrutura do aplicativo. Dada a alta flexibilidade, as funções do Azure fornecem uma ótima maneira de criar suas próprias verificações. Você inclui a lógica da função de check-in do Azure de modo que cada execução seja acionada na solicitação http, tenha um tempo de execução curto e retorne uma resposta. Ao definir a verificação, você pode analisar o corpo da resposta para inferir se a verificação foi bem-sucedida. A avaliação pode ser repetida periodicamente usando a configuração Tempo entre avaliações nas opções de controle. Saiba mais

Se a verificação não for bem-sucedida dentro do tempo limite configurado, o estágio associado será ignorado. Etapas dependendo dele também são ignoradas. Para obter mais informações, consulte a tarefa Azure Function App.

Nota

As variáveis de pipeline definidas pelo usuário são acessíveis para a verificação a partir do Sprint 215.

Leia mais sobre a maneira recomendada de usar invocar verificações de função do Azure. As verificações precisam seguir regras específicas, dependendo do seu modo e do número de novas tentativas para serem compatíveis.

Invoke REST API

Invocar a verificação da API REST permite que você se integre com qualquer um dos seus serviços existentes. Periodicamente, faça uma chamada para uma API REST e continue se ela retornar uma resposta bem-sucedida. Saiba mais

A avaliação pode ser repetida periodicamente usando a configuração Tempo entre avaliações nas opções de controle. Se a verificação não for bem-sucedida dentro do tempo limite configurado, o estágio associado será ignorado. Etapas dependendo dele também são ignoradas. Para obter mais informações, consulte Invocar tarefa de API REST.

Nota

As variáveis de pipeline definidas pelo usuário são acessíveis para a verificação a partir do Sprint 215.

Leia mais sobre a maneira recomendada de usar invocar verificações da API REST.

Consultar alertas do Azure Monitor

O Azure Monitor oferece visualização, consulta, roteamento, alerta, dimensionamento automático e automação em dados da infraestrutura do Azure e de cada recurso individual do Azure. Os alertas são um meio padrão para detetar problemas com a integridade da infraestrutura ou do aplicativo e tomar ações corretivas. Implantações canárias e distribuições em estágios são estratégias comuns de implantação usadas para reduzir o risco de regressões a aplicativos críticos. Após a implantação em um estágio (conjunto de clientes), o aplicativo é observado por um período de tempo. A integridade do aplicativo após a implantação é usada para decidir se a atualização deve ser feita para o próximo estágio ou não.

Consultar Alertas do Azure Monitor ajuda você a observar o Azure Monitor e garantir que nenhum alerta seja gerado para o aplicativo após uma implantação. A verificação será bem-sucedida se nenhuma regra de alerta for ativada no momento da avaliação. Saiba mais

A avaliação é repetida após a definição do intervalo de tempo entre as avaliações nas opções de controlo. As verificações falham se o estágio não tiver iniciado a execução dentro do período de tempo limite especificado.

Modelo obrigatório

Com a verificação de modelo necessária, você pode impor pipelines para usar um modelo YAML específico. Quando essa verificação está em vigor, um pipeline falha se não se estender a partir do modelo referenciado.

Para definir uma aprovação de modelo necessária:

1. Em seu projeto do Azure DevOps, vá para a conexão de serviço que você deseja restringir.

2. Abra Aprovações e Verificações no menu ao lado de Editar.

3. No menu Adicionar sua primeira verificação, selecione Modelo necessário.

4. Insira detalhes sobre como chegar ao arquivo de modelo necessário.

   • Tipo de repositório: o local do repositório (GitHub, Azure ou Bitbucket).
   • Repositório: o nome do repositório que contém o modelo.
   • Ref: A ramificação ou tag do modelo necessário.
   • Caminho para o modelo necessário: o nome do modelo.

Você pode ter vários modelos necessários para a mesma conexão de serviço. Neste exemplo, o modelo necessário é production_template.yaml.

Desativar uma verificação

Ao depurar uma verificação, convém desativá-la temporariamente e, em seguida, habilitá-la novamente. Para desativar ou ativar uma verificação:

1. Em seu projeto do Azure DevOps, vá para o recurso com uma verificação.

2. Abra a guia Aprovações e Verificações .

3. No menu contextual, selecione Desativar ou Ativar.

   

Ignorar uma verificação

Em algumas circunstâncias, como uma implantação de hotfix, talvez seja necessário ignorar uma verificação. Você só pode ignorar uma verificação somente se tiver a permissão de administrador para o recurso onde a verificação está definida.

Para ignorar uma aprovação, horário comercial, invocar a função do Azure ou invocar a verificação da API REST, selecione Ignorar verificação quando o recurso estiver aguardando revisão. Aqui está um exemplo de como ignorar a verificação do horário comercial.

Ao ignorar uma verificação, você verá quem ignorou a verificação no painel de verificações.

Avaliar artefato

Você pode avaliar artefatos a serem implantados em um ambiente em relação a políticas personalizadas.

Nota

Atualmente, isso funciona apenas com artefatos de imagem de contêiner

Para definir uma avaliação de política personalizada sobre os artefatos, siga as etapas abaixo.

1. Em seu projeto dos Serviços de DevOps do Azure, navegue até o ambiente que precisa ser protegido. Saiba mais sobre como criar um ambiente.

   

2. Navegue até Aprovações e verificações do ambiente.

   

3. Selecione Avaliar artefato.

   

4. Cole a definição de política e selecione Salvar. Veja mais sobre como escrever definições de política.

   

Quando você executa um pipeline, a execução dessa execução é pausada antes de entrar em um estágio que usa o ambiente. A política especificada é avaliada em relação aos metadados de imagem disponíveis. A verificação passa quando a política é bem-sucedida e falha caso contrário. O estágio é marcado como falhado se a verificação falhar.

Aprovado

Você também pode ver os logs completos das verificações de política na visualização de pipeline.

Falhado

Você também pode ver os logs completos das verificações de política na visualização de pipeline.

Fechadura exclusiva

A verificação de bloqueio exclusiva permite que apenas uma única execução do pipeline prossiga e pode ser definida no estágio ou no nível do pipeline. Todos os estágios em todas as execuções desse pipeline que usam o recurso são pausados. Quando o estágio que usa o bloqueio for concluído, outro estágio poderá continuar a usar o recurso. Além disso, apenas uma etapa pode continuar.

A lockBehavior propriedade determina como outros estágios lidam com bloqueios. Quando você especifica a lockBehavior propriedade para um estágio, um bloqueio é criado automaticamente para esse estágio. Existem dois valores possíveis lockBehavior :

• runLatest - Apenas a última execução adquire o bloqueio para o recurso. runLatest é o padrão se não lockBehavior for especificado.
• sequential - Todas as execuções adquirem o bloqueio para o recurso protegido sequencialmente.

Para usar uma verificação de bloqueio exclusiva com sequential implantações ou runLatest, siga estas etapas:

1. Habilite a verificação de bloqueio exclusiva no ambiente (ou outro recurso protegido). A opção de bloqueio exclusivo é uma verificação disponível.

   

2. No arquivo YAML para o pipeline, especifique uma propriedade chamada lockBehavior. Isso pode ser especificado para todo o pipeline ou para um determinado estágio:

Montado num palco:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Definido no pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Se você não especificar um lockBehavior e um bloqueio for definido em um recurso, o valor padrão de runLatest será usado.

Gerenciamento de alterações do ServiceNow

Essa verificação precisa que a extensão ServiceNow Change Management seja instalada a partir do marketplace

A verificação de gerenciamento de alterações do servicenow permite uma integração do processo de gerenciamento de alterações do ServiceNow nos pipelines. Ao adicionar a verificação, uma nova solicitação de alteração no ServiceNow pode ser criada automaticamente no início do estágio. O pipeline aguarda a conclusão do processo de alteração antes de iniciar o estágio. Pode ver mais detalhes aqui.

Múltiplas aprovações e verificações

Um estágio pode consistir em muitos trabalhos, e cada trabalho pode consumir vários recursos. Antes do início da execução de uma etapa, todas as verificações de todos os recursos utilizados nessa etapa devem ser satisfeitas. O Azure Pipelines pausa a execução de um pipeline antes de cada estágio e aguarda que todas as verificações pendentes sejam concluídas.

Uma única decisão final negativa faz com que o acesso ao pipeline seja negado e o estágio falhe. As decisões de todas as aprovações e verificações, exceto para invocar a função do Azure / API REST e bloqueio exclusivo são finais. Você pode executar novamente as verificações bem-sucedidas da função do Azure/API REST.

Ao usar as verificações da função do Azure / API REST da maneira recomendada, suas decisões de acesso também são finais.

Quando você especifica Tempo entre avaliações para uma verificação de função do Azure/API REST de invocação como diferente de zero, a decisão da verificação não é final. Vale a pena explorar este cenário.

Vejamos um exemplo. Imagine que seu pipeline YAML tem um estágio que usa uma conexão de serviço. Esta conexão de serviço tem duas verificações configuradas para ela:

1. Uma verificação assíncrona, chamada Aprovação Externa Concedida, que verifica se uma aprovação externa é dada e configurada da maneira recomendada.
2. Uma verificação síncrona, chamada Deployment Reason Valid, que verifica se o motivo da implantação é válido e para o qual você define o tempo entre as avaliações para 7 minutos.

Uma possível execução de verificações é mostrada no diagrama a seguir.

Nesta execução:

• Ambas as verificações, Aprovação Externa Concedida e Motivo de Implantação Válido, são invocadas ao mesmo tempo. O Motivo de Implantação Válido falha imediatamente, mas como a Aprovação Externa Concedida está pendente, ele é repetido.
• No minuto 7, o Motivo de Implantação Válido é repetido e, desta vez, passa.
• No minuto 15, a Aprovação Externa Concedida volta a ligar para o Azure Pipelines com uma decisão bem-sucedida. Agora, ambas as verificações são aprovadas, de modo que o pipeline pode continuar a implantar o estágio.

Vejamos outro exemplo, envolvendo duas verificações síncronas. Suponha que seu pipeline YAML tenha um estágio que usa uma conexão de serviço. Esta conexão de serviço tem duas verificações configuradas para ela:

1. Uma verificação síncrona, chamada Verificação de sincronização 1, para a qual você define o tempo entre as avaliações para 5 minutos.
2. Uma verificação síncrona, chamada Verificação de sincronização 2, para a qual você define o tempo entre as avaliações para 7 minutos.

Uma possível execução de verificações é mostrada no diagrama a seguir.

Nesta execução:

• Ambas as verificações, Verificação de sincronização 1 e Verificação de sincronização 2, são invocadas ao mesmo tempo. A Verificação de Sincronização 1 é aprovada, mas é repetida, porque a Verificação de Sincronização 2 falha.
• No minuto 5, a Verificação de Sincronização 1 é repetida, mas falha, por isso é repetida.
• No minuto 7, a Verificação de sincronização 2 é repetida e é bem-sucedida. A decisão de aprovação é válida por 7 minutos. Se a Verificação de Sincronização 1 não passar nesse intervalo de tempo, a Verificação de Sincronização 2 será repetida.
• No minuto 10, a Verificação de Sincronização 1 é repetida, mas falha, por isso é repetida.
• No minuto 14, a Verificação de Sincronização 2 é repetida e é bem-sucedida. A decisão de aprovação é válida por 7 minutos. Se a Verificação de Sincronização 1 não passar nesse intervalo de tempo, a Verificação de Sincronização 2 será repetida.
• No minuto 15, a Verificação de sincronização 1 é repetida e é bem-sucedida. Agora, ambas as verificações são aprovadas, de modo que o pipeline pode continuar a implantar o estágio.

Vejamos um exemplo que envolve uma aprovação e uma verificação síncrona. Imagine que você configurou uma verificação síncrona e uma aprovação para uma conexão de serviço com um intervalo de tempo entre avaliações de 5 minutos. Até que a aprovação seja dada, o seu cheque é executado a cada 5 minutos, independentemente da decisão.

FAQ

As verificações definidas não começaram. O que aconteceu?

A avaliação dos controlos tem início logo que estejam satisfeitas as condições da fase. Você deve confirmar a execução do estágio iniciado depois que as verificações foram adicionadas ao recurso e se o recurso é consumido no estágio.

Como posso usar os cheques para agendar uma etapa?

Usando a verificação de horário comercial, você pode controlar o tempo para o início da execução do estágio. Você pode obter o mesmo comportamento que o cronograma predefinido em um estágio em versões de designer.

Como posso obter aprovações antecipadas para uma etapa programada para ser executada no futuro?

Esse cenário pode ser habilitado.

1. A verificação de horário comercial permite que todos os estágios de implantação em um recurso sejam agendados para execução entre a janela de tempo
2. Quando as aprovações são configuradas no mesmo recurso, o estágio aguarda as aprovações antes de iniciar.
3. Você pode configurar ambas as verificações em um recurso. O palco aguardaria aprovações e horário comercial. Ele começaria na próxima janela agendada após a conclusão das aprovações.

Posso aguardar a conclusão da verificação de segurança no artefato que está sendo implantado?

Para aguardar a conclusão da verificação de segurança no artefato que está sendo implantado, você precisaria usar um serviço de verificação externo como o AquaScan. O artefato que está sendo implantado precisaria ser carregado em um local acessível ao serviço de varredura antes do início das verificações e pode ser identificado usando variáveis predefinidas. Usando a verificação Invoke REST API, você pode adicionar uma verificação para aguardar a API no serviço de segurança e passar o identificador de artefato como uma entrada.

Como posso utilizar variáveis de saída de fases anteriores numa verificação?

Por predefinição, apenas as variáveis predefinidas estão disponíveis para verificações. Pode utilizar um grupo de variáveis associadas para aceder a outras variáveis. A variável de saída da fase anterior pode ser escrita no grupo de variáveis e acedida na verificação.

Mais informações

• Invocar verificações da Função do Azure / API REST
• Aprovações e verificações da API REST
• API REST de consulta de aprovações