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. No entanto, 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.

    A screenshot showing how to add approvals and checks in Azure Pipelines.

  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.

    A screenshot showing how to create a new approval.

  7. Uma vez que a verificação de aprovação é acionada, uma janela de prompt, como mostrado no exemplo abaixo, é 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 screenshot showing the approval prompt window.

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.

    Screenshot of defer approval option when you respond to an approval request.

  2. Defina o tempo de aprovação.

    Screenshot of setting the time for an approval.

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

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 do check-in caso o status de proteção de uma das ramificações não seja conhecido.

    Configuring branch control check.

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.

Configuring business hours check.

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

Configuring Azure function check.

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.

Configuring required template check.

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.

    Screenshot of disable a check option.

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.

Screenshot of bypass business hours check option.

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

Screenshot of log of bypassed check.

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.

    View environment.

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

    Add checks to environment.

  3. Selecione Avaliar artefato.

    Add evaluate artifact check.

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

    Add policy definition.

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.

Viewing passed checks.

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

Viewing passed check logs.

Fechadura exclusiva

A verificação de bloqueio exclusiva permite que apenas uma única execução do pipeline prossiga. 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.

O comportamento de quaisquer outros estágios que tentam fazer um bloqueio é configurado pelo lockBehavior valor configurado no arquivo YAML para o pipeline.

  • 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 sequencialmente para o recurso protegido.

Para usar a 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).
  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, o valor padrão de runLatest será usado.

A verificação de bloqueio exclusiva permite que apenas uma única execução do pipeline prossiga. 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. Quaisquer outras etapas que tentaram fazer o bloqueio serão canceladas.

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. Diagram that shows the timeline of an asynchronous and a synchronous check's executions.

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 da Implantação Válido falha imediatamente, mas como a Aprovação Externa Concedida está pendente, ela será repetida.
  • 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. Diagram that shows the timeline of two synchronous checks' executions.

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 será 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 será 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 será 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