Definir aprovações e verificações

Azure DevOps Services

Um pipeline é composto por fases. Um autor de pipeline pode controlar se uma fase deve ser executada definindo condições na fase. Outra maneira de controlar se e quando uma fase deve ser executada é por meio de aprovações e verificações.

As 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 executadas antes do início de uma fase. Os administradores de recursos gerenciam verificações usando a interface da 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 uma fase em qualquer pipeline pode consumir um recurso. Como proprietário de um recurso, você pode definir as verificações que precisam ser satisfeitas antes que uma fase que consome o recurso possa começar. Por exemplo, uma verificação de aprovação manual em um ambiente garante que a implantação nesse ambiente só acontecesse depois que o usuário designado revisa as alterações sendo implantadas.

Uma fase pode consistir de muitos trabalhos, e cada trabalho pode consumir vários recursos. Antes que a execução de uma fase possa começar, todas as verificações em todos os recursos usados nessa fase precisam ser atendidas. O Azure Pipelines pausa a execução de um pipeline antes de cada fase e aguarda a conclusão de todas as verificações com conclusão pendente.

Existem cinco categorias de aprovações e verificações e 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, essa fase não será executada. Se qualquer uma das verificações falhar terminalmente (por exemplo, se você rejeitar uma aprovação em um dos recursos), essa fase não será executada.

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

1. Verificações estáticas: controle de ramificação, modelo necessário e artefato de avaliação
2. Aprovações de pré-verificação
3. Verificações dinâmicas: Aprovação, Invocar Azure Function, Invocar API REST, Horário comercial, Consultar alertas do Azure Monitor
4. Aprovações pós-verificação
5. Bloqueio exclusivo

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

Aprovações

Você pode controlar manualmente quando uma fase deve ser executada usando aprovações e verificações. Essas verificações geralmente são usadas para controlar implantações em ambientes de produção.

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

2. Selecione Pipelines>Ambientes e em seguida selecione seu ambiente.

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

   

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

5. Adicione usuários ou grupos como seus Aprovadoresdesignados e, se desejar, forneça instruções para os aprovadores. Especifique se você deseja permitir ou restringir que os aprovadores aprovem suas próprias execuções e especifique o tempo limite desejado. Se as aprovações não forem concluídas no tempo limite especificado, a fase será marcada como ignorada.

6. Selecione Criar quando terminar.

   

7. Depois que a verificação de aprovação é acionada, uma janela de prompt, conforme 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 é corrigida 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 após o início da execução das verificações não são realizadas.

Controle de branch

Usando a verificação do controle de branch, você pode garantir que todos os recursos vinculados ao pipeline sejam criados a partir dos branches permitidos e que os branches tenham a proteção habilitada. Essa verificação ajuda a controlar a preparação da versão e a qualidade das implantações. Caso vários recursos estejam vinculados ao pipeline, a origem de todos os recursos será verificada. Se você tiver vinculado outro pipeline, o branch da execução específica que está sendo implantada será verificado para proteção.

Para definir a verificação do controle de branch:

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

2. Navegue para Aprovações e Verificações do recurso.

3. Escolha a verificação Controle de branch e forneça uma lista separada por vírgulas de branches permitidos. Você pode exigir que o branch tenha a proteção habilitada. Você também pode definir o comportamento da verificação se o status de proteção para um dos branches 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 branches para todos os recursos vinculados na execução em relação à lista de permitidos. Se qualquer um dos branches não corresponder aos critérios, a verificação falhará e a fase será marcada como com falha.

Horário comercial

Caso você queira que todas as implantações em seu ambiente ocorram apenas em uma janela de tempo específica, a verificação em horário comercial é a solução ideal. Quando você executa um pipeline, a execução da fase 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 maneira independente. No início do horário comercial, a verificação é marcada como bem-sucedida para todas as execuções.

Se a execução da fase não tiver sido iniciada até o término do horário comercial (impedida por alguma outra verificação), a aprovação em horário comercial será retirada automaticamente e uma reavaliação será agendada para o dia seguinte. A verificação falhará se a execução da fase não for iniciada dentro do período de Tempo limite especificado para a verificação e a fase será marcada como com falha.

Invocar uma 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 pequenas partes de código (chamadas de "funções") sem se preocupar com a infraestrutura do aplicativo. Dada a alta flexibilidade, as funções do Azure são uma ótima maneira de criar suas verificações. Você inclui a lógica da função de verificação do Azure de forma 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 tiver êxito no Tempo Limite configurado, o estágio associado será ignorado. As fases que dependem disso também serão ignoradas. Para obter mais informações, consulte a tarefa aplicativo de funções do Azure.

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 modo e do número de tentativas a serem compatíveis.

Invocar API REST

Invocar a verificação de API REST permite que você se integre a qualquer um dos serviços existentes. Periodicamente, faça uma chamada a 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 tiver êxito no Tempo Limite configurado, o estágio associado será ignorado. As fases que dependem disso também serão ignoradas. Para obter mais informações, consulte Invocar tarefa da API REST.

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

Consultar alertas do Azure Monitor

O Azure Monitor oferece visualização, consulta, roteamento, alertas, dimensionamento automático e automação nos dados da infraestrutura do Azure e de cada recurso do Azure individual. Os alertas são um meio padrão para detectar problemas com a integridade da infraestrutura ou do aplicativo e executar ações corretivas. Implantações canário e distribuições em etapas são estratégias de implantação comuns usadas para reduzir o risco de regressões para aplicativos críticos. Depois de implantar em uma fase (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 a próxima fase 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 terá êxito se nenhuma regra de alerta for ativada no momento da avaliação. Saiba mais

A avaliação será repetida após a configuração Tempo entre avaliações nas opções de controle. As verificações falharão se a fase não tiver iniciado a execução dentro do período de Tempo limite especificado.

Modelo necessário

Com a verificação de modelo necessária, você pode impor o uso de um modelo YAML específico nos pipelines. Quando essa verificação estiver em vigor, um pipeline falhará se ele não se estender do modelo referenciado.

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

1. Em seu projeto do Azure DevOps, acesse 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 exigido.

4. Insira detalhes sobre como acessar o arquivo de modelo exigido.

   • 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: o branch ou tag do modelo exigido.
   • Caminho para o modelo exigido: o nome do modelo.

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

Avaliar artefato

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

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

1. No seu projeto do Azure DevOps Services, vá para o ambiente que precisa ser protegido. Saiba mais sobre: criar um ambiente.

   

2. Navegue para 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, essa execução é pausada antes de entrar em uma fase que usa o ambiente. A política especificada é avaliada em relação aos metadados de imagem disponíveis. A verificação é aprovada quando a política é bem-sucedida; caso contrário, ela falha. A fase será marcada como com falha se a verificação falhar.

Bloqueio exclusivo

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

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

Gerenciamento de Alterações do ServiceNow

Essas verificações precisam que a extensão de Gerenciamento de Alterações do ServiceNow seja instalada 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 da fase. O pipeline aguarda a conclusão do processo de alteração antes de iniciar a fase. Mais detalhes estão disponíveis aqui.

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

Uma fase pode consistir de muitos trabalhos, e cada trabalho pode consumir vários recursos. Antes que a execução de uma fase possa começar, todas as verificações em todos os recursos usados nessa fase precisam ser atendidas. O Azure Pipelines pausa a execução de um pipeline antes de cada fase e aguarda a conclusão de todas as verificações com conclusão pendente.

Uma decisão final negativa é suficiente para que o acesso seja negado ao pipeline e a fase falhe. As decisões de todas as aprovações e verificações, exceto invocar função do Azure/API REST e Bloqueio exclusivo, são finais. Você pode executar novamente as verificações de invocar função do Azure/API REST bem-sucedidas.

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

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

Vamos ver um exemplo. Imagine que seu pipeline YAML tem uma fase que usa uma conexão de serviço. Essa conexão de serviço tem duas verificações configuradas para ela:

1. Uma verificação assíncrona, chamado de Aprovação Externa Concedida, que verifica se uma aprovação externa é fornecida e configurada da maneira recomendada.
2. Uma verificação síncrona, chamada de Motivo de Implantação Válido, que verifica se o motivo da implantação é válido e para a qual você define o Tempo entre avaliações como sete 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. A Motivo de Implantação Válido falha imediatamente, mas como a Aprovação Externa Concedida está pendente, ela será repetida.
• No minuto sete, a Motivo de Implantação Válido é repetida e, desta vez, é aprovada.
• No minuto 15, a Aprovação Externa Concedida retorna para o Azure Pipelines com uma decisão bem-sucedida. Agora, ambas as verificações são aprovadas, portanto, o pipeline tem permissão para continuar a implantar a fase.

Vejamos outro exemplo, envolvendo duas verificações síncronas. Suponha que seu pipeline YAML tenha uma fase que usa uma conexão de serviço. Essa 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 avaliações como cinco 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 como sete 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 será repetida, pois a Verificação de Sincronização 2 falha.
• No minuto 5, a Verificação de Sincronização 1 é repetida, mas falha, portanto, ela será repetida outra vez.
• No minuto sete, a Verificação de Sincronização 2 é repetida e tem êxito. A decisão de aprovação é válida por sete minutos. Se a Verificação de Sincronização 1 não for aprovada 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, portanto, ela será repetida outra vez.
• No minuto 14, a Verificação de Sincronização 2 é repetida e tem êxito. A decisão de aprovação é válida por sete minutos. Se a Verificação de Sincronização 1 não for aprovada 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 tem êxito. Agora, ambas as verificações são aprovadas, portanto, o pipeline tem permissão para continuar a implantar a fase.

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 Tempo entre avaliações de cinco minutos. Até que a aprovação seja dada, sua verificação é executada a cada cinco minutos, independentemente da decisão.

Perguntas frequentes

As verificações definidas não foram iniciadas. O que aconteceu?

A avaliação das verificações começa depois que as condições da fase são atendidas. Você deve confirmar que a execução da fase foi iniciada depois que as verificações foram adicionadas no recurso e se o recurso é consumido na fase.

Como posso usar verificações para agendar uma fase?

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

Como posso obter aprovações antecipadas para uma fase agendada para ser executada no futuro?

Esse cenário pode ser habilitado.

1. A verificação em horário comercial permite que todas as fases de implantação em um recurso sejam agendadas para execução entre uma janela de tempo
2. Quando as aprovações são configuradas no mesmo recurso, a fase aguarda pelas aprovações antes de iniciar.
3. Você pode configurar as duas verificações em um recurso. A fase aguardaria as aprovações e o horário comercial. Ela 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ê precisará 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 para o serviço de verificação antes do início das verificações e pode ser identificado usando variáveis predefinidas. Usando a verificação Invocar API REST, 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 usar variáveis de saída de estágios anteriores em um verificação?

Por padrão, somente variáveis predefinidas estão disponíveis para verificações. Você pode usar um grupo de variáveis vinculado para acessar outras variáveis. A variável de saída do estágio anterior pode ser gravada no grupo de variáveis e acessada na verificação.

Saiba mais

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