Definir aprovações e verificações

Azure DevOps Services

Um pipeline é composto por estágios. 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 um estágio deve ser executado é por meio de aprovações e verificações.

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 atendidas antes que um estágio de consumo desse recurso possa ser iniciado. Por exemplo, uma verificação de aprovação manual em um ambiente garantiria que a implantação nesse ambiente só ocorresse depois que os usuários designados revisarem 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 que a execução de um estágio possa começar, todas as verificações em todos os recursos usados nesse estágio devem ser atendidas. O Azure Pipelines pausa a execução de um pipeline antes de cada estágio e aguarda a conclusão de todas as verificações pendentes. 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 qualquer uma das verificações falhar terminalmente (por exemplo, se você rejeitar uma aprovação em um dos recursos), esse estágio não será executado.

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 um estágio. Os administradores de recursos gerenciam verificações usando a interface da Web do Azure Pipelines.

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 verificações de aprovação. Essa verificação é comumente usada para controlar implantações em ambientes de produção.

1. Em 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. Selecione Criar, forneça os aprovadores e uma mensagem opcional e selecione Criar novamente para concluir a adição da verificação de aprovação manual.

Você pode adicionar vários aprovadores a um ambiente. Esses aprovadores podem ser usuários individuais ou grupos de usuários. Quando um grupo é especificado como aprovador, apenas um dos usuários desse grupo precisa aprovar para que a execução avance.

Usando as opções avançadas, você pode configurar o número mínimo de aprovadores para concluir a aprovação. Um grupo é considerado como um aprovador.

Você também pode restringir o usuário que solicitou (iniciou ou criou) a execução de concluir a aprovação. Essa opção é comumente usada para segregação de funções entre os usuários.

Quando você executa um pipeline, a execução dessa execução é pausada antes de entrar em um estágio que usa o ambiente. Os usuários configurados como aprovadores devem examinar e aprovar ou rejeitar a implantação. Se você tiver várias execuções em execução simultaneamente, deverá aprovar ou rejeitar cada uma delas de forma independente. Se todas as aprovações necessárias não forem concluídas no Tempo limite especificado para a aprovação e todas as outras verificações forem bem-sucedidas, o estágio será marcado como ignorado.

Controle de ramificação

Usando a verificação de 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 de controle de branch:

1. Em 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 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 caso o status de proteção de caso de um dos branches não seja conhecido.

Em tempo de execução, a verificação validaria branches para todos os recursos vinculados na execução em relação à lista permitida. Se qualquer um dos branches não corresponder aos critérios, a verificação falhará e o estágio será marcado como com falha.

Observação

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

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 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 independentemente. No início do horário comercial, a verificação é marcada como bem-sucedida para todas as execuções.

Se a execução do estágio não tiver sido iniciada no final do horário comercial (mantida por alguma outra verificação), a aprovação do horário comercial será retirada automaticamente e uma reavaliação será agendada para o dia seguinte. A verificação falhará se a execução do estágio não for iniciada dentro do período de tempo limite especificado para a verificação e o estágio estiver marcado como com falha.

Invocar 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 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 disparada na solicitação http, tenha um curto tempo de execução e retorne uma resposta. Ao definir a verificação, você pode analisar o corpo da resposta para inferir se a verificação for bem-sucedida. A avaliação pode ser repetida periodicamente usando a configuração Tempo entre avaliações nas opções de controle. Saiba mais

As verificações falharão se o estágio não tiver iniciado a execução dentro do período de tempo limite especificado. Confira a tarefa Aplicativo de Funções do Azure para obter mais detalhes.

Observação

As variáveis de pipeline definidas pelo usuário não podem ser acessadas pela verificação. Você só pode acessar as variáveis e variáveis predefinidas do grupo de variáveis vinculados no corpo da solicitação.

Leia mais sobre a maneira recomendada de usar Invocar verificações de Função do Azure.

Invocar a API REST

Invocar a verificação da API REST permite que você se integre a 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. As verificações falharão se o estágio não tiver iniciado a execução dentro do período de tempo limite especificado. Consulte Invocar tarefa da API REST para obter mais detalhes.

Observação

As variáveis de pipeline definidas pelo usuário não podem ser acessadas pela verificação. Você só pode acessar as variáveis e variáveis predefinidas do grupo de variáveis vinculados no corpo da solicitação.

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 em dados da infraestrutura do Azure e de cada recurso individual do Azure. 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árias 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 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 terá êxito se nenhuma regra de alerta for ativada no momento da avaliação. Saiba mais

A avaliação é repetida após a configuração Tempo entre avaliações nas opções de controle. As verificações falharão se o estágio 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 pipelines para usar um modelo YAML específico. 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 obrigatório.

4. Insira detalhes sobre como acessar o 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 marca 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 é required.yml.

Avaliar artefato

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

Observação

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 de Azure DevOps Services, navegue até o ambiente que precisa ser protegido. Saiba mais sobre como criar um ambiente.

2. Navegue até Aprovações e verifique o ambiente.

3. Selecione Avaliar artefato.

4. Cole a definição de política e clique em 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 é aprovada quando a política é bem-sucedida e falha de outra forma. O estágio será marcado como com falha se a verificação falhar.

Aprovado

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

Com falha

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

Bloqueio exclusivo

A verificação de bloqueio exclusiva permite que apenas uma única execução do pipeline prossiga. Todas as fases em todas as execuções desse pipeline que usam o recurso são pausadas. Quando o estágio que usa o bloqueio é concluído, outro estágio pode continuar a usar o recurso. Além disso, somente um estágio poderá continuar.

O comportamento de quaisquer outras fases que tentam fazer um bloqueio é configurado pelo lockBehavior valor configurado no arquivo YAML para o pipeline.

• runLatest – Somente a execução mais recente adquire o bloqueio para o recurso. runLatest será o padrão se não lockBehavior for especificado.
• sequential – Todas as execuções adquirem o bloqueio sequencialmente ao 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 em outro recurso protegido).
2. No arquivo YAML do pipeline, especifique uma propriedade chamada lockBehavior. Isso pode ser especificado para todo o pipeline ou para um determinado estágio:

Definido em um estágio:

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

Definir 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. Todas as fases em todas as execuções desse pipeline que usam o recurso são pausadas. Quando o estágio que usa o bloqueio é concluído, outro estágio pode continuar a usar o recurso. Além disso, somente um estágio poderá continuar. Todas as outras fases que tentaram executar o bloqueio serão canceladas.

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 do estágio. O pipeline aguarda a conclusão do processo de alteração antes de iniciar o estágio. Mais detalhes estão disponíveis aqui.

Várias aprovações e verificações

Um estágio pode consistir em muitos trabalhos e cada trabalho pode consumir vários recursos. Antes que a execução de um estágio possa começar, todas as verificações em todos os recursos usados nesse estágio devem ser atendidas. O Azure Pipelines pausa a execução de um pipeline antes de cada estágio e aguarda a conclusão de todas as verificações pendentes.

Uma única decisão negativa final faz com que o pipeline seja negado acesso e o estágio falhe. As decisões de todas as Aprovações e Verificações, exceto para Invocar Função do Azure/API REST e Bloqueio exclusivo , são finais.

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

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

Vamos examinar 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 é fornecida e configurada da maneira recomendada.
2. Uma verificação síncrona, chamada Motivo de Implantação Válido, que verifica se o motivo da implantação é válido e para o qual você define o Tempo entre avaliações como 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álida, 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 da Implantação Válido é repetido e, desta vez, ele passa.
• No minuto 15, a Aprovação Externa concedeu chamadas de volta ao 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 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 avaliações como 5 minutos.
2. Uma verificação síncrona, chamada Verificação de Sincronização 2, para a qual você definiu a Hora entre as avaliações como 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 Sincronização Verificação 1 passa, mas será repetida, pois a Verificação de Sincronização 2 falhará.
• No minuto 5, a Verificação de Sincronização 1 é repetida, mas falha, portanto, ela 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, portanto, ela 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, portanto, o pipeline tem permissão para 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 Tempo entre avaliações de 5 minutos. Até que a aprovação seja dada, sua verificação será executada a cada 5 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 quando as condições de estágio são atendidas. Você deve confirmar a execução do estágio iniciado depois que as verificações foram adicionadas no recurso e se o recurso é consumido no estágio.

Como posso usar verificações para agendar um estágio?

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 agendamento predefinido em um estágio em versões de designer.

Como posso obter aprovações antecipadas para um estágio agendado para ser executado no futuro?

Esse cenário pode ser habilitado

1. A verificação de horário comercial permite que todas as fases de implantação em um recurso sejam agendadas para execução entre a janela de tempo
2. Quando as aprovações são configuradas no mesmo recurso, o estágio aguardaria aprovações antes de iniciar.
3. Você pode configurar as duas verificações em um recurso. O estágio aguardaria as aprovações e o 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ê 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 uma 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.