Usar gatilhos para controlar quando o pipeline é executado
Agora você tem um pipeline de trabalho que implanta o arquivo Bicep em seu ambiente do Azure. No entanto, sempre que alterar os arquivos, você deverá executar manualmente o seu pipeline. Nesta unidade, você aprenderá a disparar seu pipeline para executar automaticamente sempre que o código Bicep for atualizado.
Observação
Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você praticará o que aprendeu aqui em breve.
O que é um gatilho de pipeline?
Um gatilho de pipeline é uma condição que, quando atendida, executa automaticamente o pipeline com base nas regras que você cria. Você pode definir gatilhos para executar seu pipeline em intervalos agendados. Você também pode definir gatilhos para executar o seu pipeline sempre que um arquivo do seu repositório mudar. Convém escolher a segunda opção, pois o ideal é executar todos os testes e as etapas de implantação sempre que alguém altera o código.
Se você não usar um gatilho automático, alguém poderá fazer uma alteração em um arquivo Bicep e até mesmo confirmá-lo e efetuar push dele para o repositório. Mas, se eles esquecerem de executar o pipeline, haverá uma diferença entre as definições de recurso em seu arquivo Bicep e os recursos implantados em seu ambiente do Azure. Suponha que mais algumas confirmações e pushes sejam feitos, mas não implantados. Se alguém apresentar um erro ou uma configuração incorreta no arquivo Bicep em uma dessas alterações, poderá ser difícil rastrear o erro entre as várias confirmações implantadas posteriormente ao mesmo tempo. Após algum tempo, você não confiará que seu código Bicep realmente representa sua infraestrutura e seu ele não terá mais valor.
Quando você configura seu pipeline para ser executado sempre que atualiza seus arquivos, no momento em que suas alterações são enviadas por push, o pipeline começa a ser executado. Você pode receber comentários instantâneos sobre a validade da alteração e ter a certeza de que seu ambiente de produção está sempre atualizado.
Gatilhos de branch
Um tipo de gatilho comum é um gatilho de ramificação, também conhecido como gatilho de integração contínua ou gatilho de CI. Quando você usa um gatilho de ramificação, sempre que fizer uma alteração em uma ramificação específica, o pipeline é executado. Se você fizer commit e efetuar push de uma alteração para um branch diferente, o pipeline não será disparado e não será executado. É comum usar esse tipo de gatilho em relação à sua ramificação main com este código:
trigger:
- main
Disparar quando vários branches mudarem
Você pode configurar gatilhos para executar seu pipeline em uma ramificação específica ou em conjuntos de ramificações. Por exemplo, suponha que você crie branches de versão que contenham o código que vai implantar para uma versão específica do seu projeto. Você pode usar nomes de ramificações como release/v1, release/v2 e assim por diante. Você deseja executar o pipeline sempre que o código mudar em um branch que comece com o nome release/. Você pode usar a propriedade include com um curinga *:
trigger:
branches:
include:
- main
- release/*
Você também pode excluir ramificações específicas. Digamos que você esteja colaborando com membros da equipe em seu projeto. Seus colegas criam branches de recursos para experimentar suas ideias em arquivos Bicep. Todas essas ramificações de recursos têm nomes como feature/add-database, feature/improve-performance e assim por diante. Você deseja executar seu pipeline automaticamente em todas as ramificações, exceto as ramificações de recursos que seus colegas criaram. Usando a propriedade exclude, você faz com que o pipeline não seja disparado automaticamente para alterações em ramificações de recursos:
trigger:
branches:
include:
- '*'
exclude:
- feature/*
Dica
Observe as aspas ao redor do curinga no filtro include. O formato de arquivo YAML exige que você coloque um único caractere * entre aspas ao usá-lo como um curinga.
Filtros de caminho
Às vezes, você tem arquivos em seu repositório que não estão relacionados à sua implantação. Por exemplo, você pode ter uma pasta implantar em seu repositório que contém o código Bicep e uma pasta docs separada que contém os arquivos de documentação. Você deseja disparar seu pipeline quando alguém faz uma alteração em um dos arquivos Bicep na pasta implantar, mas não quiser disparar o pipeline se alguém apenas alterar um arquivo de documentação. Para configurar um gatilho para responder a alterações em uma pasta específica do seu repositório, você pode usar um filtro de caminho:
trigger:
branches:
include:
- main
paths:
exclude:
- docs
include:
- deploy
Se alguém confirmar uma alteração que atualize apenas um arquivo de documentação, o pipeline não será executado. Mas se alguém alterar um arquivo do Bicep ou mesmo se uma pessoa alterar um arquivo do Bicep adicionalmente a um arquivo de documentação, o gatilho executará o pipeline.
Agendar seu pipeline para ser executado automaticamente
Você pode executar o pipeline em um agendamento definido e não em resposta a uma alteração de arquivo. Por exemplo, você pode executar uma versão noturna do código Bicep ou implantar automaticamente um ambiente de teste todas as manhãs. Use a palavra-chave schedules em vez de trigger e defina a frequência usando uma expressão cron:
schedules:
- cron: "0 0 * * *"
displayName: Daily environment restore
branches:
include:
- main
Observação
Uma expressão cron é uma sequência de caracteres especialmente formatada que define com que frequência um evento deve acontecer. Neste exemplo, 0 0 * * * significa executar todos os dias à meia-noite UTC.
Você também pode definir a ramificação do repositório a ser usada no evento agendado. Quando o pipeline é iniciado, ele usa a versão mais recente do código da ramificação definido na agenda.
Usar vários gatilhos
Você pode combinar gatilhos e agendamentos, como neste exemplo:
trigger:
- main
schedules:
- cron: "0 0 * * *"
displayName: Deploy test environment
branches:
include:
- main
Quando você cria um gatilho de branch e um gatilho agendado no mesmo pipeline, o pipeline é executado sempre que um arquivo é alterado no branch definido no gatilho e na agenda definida. Neste exemplo, o pipeline é executado todos os dias à meia-noite UTC e também sempre que uma alteração é enviada por push para a ramificação principal.
Dica
Uma boa prática é definir gatilhos para cada pipeline. Se você não definir gatilhos, por padrão, o pipeline será executado automaticamente sempre que qualquer arquivo for alterado em qualquer ramificação, o que geralmente não é o desejável.
Controle de simultaneidade
Por padrão, o Azure Pipelines permite que várias instâncias do seu pipeline sejam executadas simultaneamente. Isso pode acontecer quando você faz vários commits em um branch dentro de um curto período de tempo.
Em algumas situações, ter várias execuções simultâneas do seu pipeline não é um problema. Mas quando você trabalha com pipelines de implantação, pode ser desafiador garantir que as execuções de pipeline não estejam substituindo os recursos ou a configuração do Azure de maneiras que você não esperava.
Para evitar esses problemas, você pode usar a palavra-chave batch com um gatilho, como neste exemplo:
trigger:
batch: true
branches:
include:
- main
Quando o gatilho é acionado, o Azure Pipelines garante que ele aguarde a conclusão de qualquer execução de pipeline ativa. Em seguida, ele inicia uma nova execução com todas as alterações acumuladas desde a última execução.