Use gatilhos para controlar quando o pipeline é executado
Agora você tem um pipeline de trabalho que implanta seu arquivo Bicep em seu ambiente do Azure. No entanto, sempre que você alterar o arquivo, você deve executar manualmente o pipeline. Nesta unidade, você aprenderá como acionar seu pipeline para ser executado automaticamente sempre que o código do Bíceps mudar.
Nota
Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você vai praticar o que você aprende aqui em breve.
O que é um gatilho de pipeline?
Um gatilho de pipeline é uma condição que, quando atendida, executa automaticamente seu pipeline com base nas regras criadas. Você pode definir gatilhos para executar seu pipeline em intervalos agendados. Você também pode definir gatilhos para executar seu pipeline sempre que um arquivo no repositório for alterado. Você pode escolher a segunda opção porque é uma boa ideia executar todos os seus testes e etapas de implantação sempre que alguém alterar seu código.
Se você não usar um gatilho automático, alguém pode fazer uma alteração em um arquivo Bicep e até mesmo confirmá-lo e enviá-lo por push para o repositório. Mas se eles se esquecerem de executar o pipeline, haverá uma diferença entre as definições de recursos em seu arquivo Bicep e os recursos que são implantados em seu ambiente do Azure. Suponha que mais alguns commits e pushes sejam feitos, mas não implantados. Se alguém introduzir um erro ou configuração incorreta no arquivo Bicep em uma dessas alterações, pode ser difícil rastrear o erro entre as várias confirmações que são implantadas posteriormente de uma só vez. Depois de um tempo, você não confiará que seu código Bicep realmente representa sua infraestrutura e seu valor será corroído.
Quando você configura seu pipeline para ser executado toda vez que atualiza seus arquivos, no momento em que suas alterações são enviadas por push, seu pipeline começa a ser executado. Você recebe feedback instantâneo sobre a validade de sua alteração e pode ter certeza de que seu ambiente de produção está sempre atualizado.
Gatilhos de ramificação
Um tipo comum de gatilho é um gatilho de ramificação, também chamado de gatilho de integração contínua ou gatilho de CI. Quando você usa um gatilho de ramificação, toda vez que você faz uma alteração em uma ramificação específica, o pipeline é executado. Se você confirmar e enviar uma alteração para uma ramificação diferente, o pipeline não será acionado e não será executado. É comum usar esse tipo de gatilho contra sua ramificação padrão ou principal , com este código:
trigger:
- main
Acionar quando várias ramificações mudam
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 ramificações de versão que contenham o código que você 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 seu pipeline sempre que seu código for alterado em uma ramificação que comece com o nome release/. Você pode usar a propriedade com um * curingainclude:
trigger:
branches:
include:
- main
- release/*
Você também pode excluir ramificações específicas. Suponha que você esteja colaborando com membros da equipe em seu projeto. Seus colegas criam ramificações de recursos para experimentar suas ideias em arquivos Bicep. Todas as ramificações de recursos têm nomes como recurso/adicionar banco de dados, recurso/melhorar o desempenho e assim por diante. Você deseja executar seu pipeline automaticamente em todas as ramificações, exceto nas ramificações de recursos criadas por seus colegas. Ao usar a exclude propriedade, você garante que o pipeline não seja acionado automaticamente para alterações em ramificações de recursos:
trigger:
branches:
include:
- '*'
exclude:
- feature/*
Gorjeta
Observe as aspas ao redor do curinga include no filtro. O formato de arquivo YAML requer que você coloque um único * caractere entre aspas ao usá-lo como 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 deploy em seu repositório que contenha seu código Bicep e uma pasta docs separada que contenha seus arquivos de documentação. Você deseja acionar seu pipeline quando alguém fizer uma alteração em qualquer um dos arquivos Bicep na pasta deploy , mas não deseja acionar o pipeline se alguém alterar apenas um arquivo de documentação. Para configurar um gatilho para responder a alterações em uma pasta específica no 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 Bicep, ou mesmo se alterar um arquivo Bicep além de um arquivo de documentação, o gatilho executa o pipeline.
Programe seu pipeline para ser executado automaticamente
Você pode executar seu pipeline em um cronograma definido e não em resposta a uma alteração de arquivo. Por exemplo, você pode executar uma versão noturna do seu código Bicep ou implantar automaticamente um ambiente de teste todas as manhãs. Use a schedules palavra-chave 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
Nota
Uma expressão cron é uma sequência de caracteres especialmente formatada que define a frequência com que um evento acontecerá. Neste exemplo, 0 0 * * * significa executar todos os dias à meia-noite UTC.
Você também pode definir a ramificação do repositório para usar no evento agendado. Quando o pipeline é iniciado, ele usa a versão mais recente do código da ramificação definida na agenda.
Usar vários gatilhos
Você pode combinar gatilhos e agendas, como neste exemplo:
trigger:
- main
schedules:
- cron: "0 0 * * *"
displayName: Deploy test environment
branches:
include:
- main
Quando você cria um gatilho de ramificação e um gatilho agendado no mesmo pipeline, o pipeline é executado sempre que um arquivo é alterado na ramificação definida 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 para a ramificação principal .
Gorjeta
É uma boa prática definir gatilhos para cada pipeline. Se você não definir gatilhos, por padrão, seu pipeline será executado automaticamente sempre que qualquer arquivo for alterado em qualquer ramificação, o que muitas vezes não é o que você deseja.
Controlo 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árias confirmações em uma ramificação em um curto espaço 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 um desafio garantir que suas execuções de pipeline não estejam substituindo seus recursos ou configuração do Azure de maneiras que você não espera.
Para evitar esses problemas, você pode usar a batch palavra-chave 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 ativo. Em seguida, ele inicia uma nova execução com todas as alterações que se acumularam desde a última execução.