Uso de desencadenadores para controlar cuándo se ejecuta una canalización
Ahora tiene una canalización en funcionamiento que implementa el archivo de Bicep en el entorno de Azure. Sin embargo, cada vez que cambie el archivo, debe ejecutar manualmente la canalización. En esta unidad, aprenderá a desencadenar la canalización para que se ejecute automáticamente cada vez que cambie el código de Bicep.
Nota:
Los comandos de esta unidad se muestran para ilustrar conceptos. No los ejecute todavía. Pronto va a practicar lo que aprenderá aquí.
¿Qué es un desencadenador de una canalización?
Un desencadenador de una canalización es una condición que, cuando se cumple, ejecuta automáticamente la canalización en función de las reglas que cree. Puede establecer desencadenadores para ejecutar la canalización a intervalos programados. También puede establecer desencadenadores para ejecutar la canalización cada vez que cambie un archivo del repositorio. Es posible que elija la segunda opción porque es recomendable ejecutar todas las pruebas y los pasos de implementación cada vez que alguien cambie el código.
Si no usa un desencadenador automático, otras personas podrían realizar un cambio en un archivo de Bicep e incluso confirmarlo e insertarlo en el repositorio. Pero, si olvidan ejecutar la canalización, habrá una diferencia entre las definiciones de recursos del archivo de Bicep y los recursos que se implementan en el entorno de Azure. Supongamos que se realizan un par de confirmaciones e inserciones más, pero no se implementan. Si alguien introduce un error o una configuración incorrecta en el archivo de Bicep en uno de estos cambios, puede ser difícil realizar un seguimiento del error entre las múltiples confirmaciones que se implementen más adelante a la vez. Después de un tiempo, no confiará en que el código de Bicep represente realmente la infraestructura y su valor se ha deteriorado.
Si configura la canalización para que se ejecute cada vez que actualice los archivos, la canalización comienza a ejecutarse en el momento en el que se inserten los cambios. Obtiene información inmediata sobre la validez del cambio y puede tener la seguridad de que el entorno de producción siempre está actualizado.
Desencadenadores de rama
Un tipo de desencadenador común es un desencadenador de rama, también denominado desencadenador de integración continua o desencadenador de CI. Si usa un desencadenador de rama, cada vez que se realiza un cambio en una rama específica, se ejecuta la canalización. Si confirma e inserta un cambio en otra rama, no se desencadena la canalización y no se ejecuta. Es habitual usar este tipo de desencadenador en la rama principal o predeterminada, con este código:
trigger:
- main
Desencadenador cuando cambian varias ramas
Puede configurar desencadenadores para ejecutar la canalización en una rama específica o en conjuntos de ramas. Por ejemplo, supongamos que crea ramas de versión que contienen el código que va a implementar para una versión específica del proyecto. Puede usar nombres de rama como release/v1, release/v2, etc. Puede ejecutar la canalización cada vez que el código cambie en una rama que comience con el nombre release/. Puede usar la propiedad include con el carácter comodín *:
trigger:
branches:
include:
- main
- release/*
También puede excluir ramas concretas. Supongamos que está colaborando con los miembros del equipo en el proyecto. Sus compañeros crean ramas de características para probar sus ideas en archivos de Bicep. Todas las ramas de características tienen nombres como feature/add-database, feature/improve-performance, etc. Puede ejecutar la canalización automáticamente en todas las ramas, excepto en las ramas de características que creen sus compañeros. Al usar la propiedad exclude, se asegura de que la canalización no se desencadene automáticamente por cambios en las ramas de características:
trigger:
branches:
include:
- '*'
exclude:
- feature/*
Sugerencia
Observe las comillas del carácter comodín en el filtro include. El formato de archivo de YAML requiere poner un solo carácter * entre comillas cuando se usa como carácter comodín.
Filtros de ruta de acceso
A veces, tiene archivos en el repositorio que no están relacionados con la implementación. Por ejemplo, es posible que tenga en el repositorio una carpeta deploy que contenga el código de Bicep y una carpeta docs aparte que contenga los archivos de la documentación. Supongamos que desea desencadenar la canalización cuando alguien realice un cambio en cualquiera de los archivos de Bicep de la carpeta deploy, pero no quiere desencadenar la canalización si alguien cambia solo un archivo de la documentación. Para configurar un desencadenador que responda a los cambios de una carpeta específica del repositorio, puede usar un filtro de ruta de acceso:
trigger:
branches:
include:
- main
paths:
exclude:
- docs
include:
- deploy
Si alguien confirma un cambio que solo actualiza un archivo de la documentación, la canalización no se ejecuta. Pero si alguien cambia un archivo de Bicep, o incluso si cambia un archivo de Bicep y un archivo de la documentación, el desencadenador ejecuta la canalización.
Programación de la canalización para que se ejecute automáticamente
Puede ejecutar la canalización según una programación establecida y no en respuesta a un cambio en un archivo. Por ejemplo, puede ejecutar una versión del código de Bicep por la noche o implementar automáticamente un entorno de prueba cada mañana. Use la palabra clave schedules en lugar de trigger y especifique la frecuencia con la expresión cron:
schedules:
- cron: "0 0 * * *"
displayName: Daily environment restore
branches:
include:
- main
Nota:
Una expresión cron es una secuencia de caracteres con un formato específico que establece la frecuencia con la que debe ocurrir un evento. En este ejemplo, 0 0 * * * significa ejecutarse todos los días a medianoche UTC.
También puede establecer la rama del repositorio para usarla en el evento programado. Cuando se inicia la canalización, usa la versión más reciente del código de la rama que estableció en la programación.
Uso de varios desencadenadores
Puede combinar desencadenadores y programaciones, como en este ejemplo:
trigger:
- main
schedules:
- cron: "0 0 * * *"
displayName: Deploy test environment
branches:
include:
- main
Cuando se crean un desencadenador de rama y un desencadenador programado en la misma canalización, la canalización se ejecuta cada vez que cambia un archivo en la rama especificada en el desencadenador y según la programación establecida. En este ejemplo, la canalización se ejecuta todos los días a medianoche (UTC) y también siempre que se inserta un cambio en la rama principal.
Sugerencia
Es recomendable especificar desencadenadores para cada canalización. Si no lo hace, la canalización se ejecuta automáticamente de forma predeterminada cada vez que se produce algún cambio en un archivo de cualquier rama, que no suele ser lo deseado.
Control de simultaneidad
De forma predeterminada, Azure Pipelines permite que varias instancias de la canalización se ejecuten de manera simultánea. Esto puede ocurrir cuando se realizan varias confirmaciones en una rama en un breve período de tiempo.
En algunas situaciones, tener varias ejecuciones simultáneas de la canalización no es un problema. Pero cuando se trabaja con canalizaciones de implementación, puede ser difícil asegurarse de que las ejecuciones de canalización no sobrescriban los recursos o la configuración de Azure de maneras que no se esperan.
Para evitar estos problemas, puede usar la palabra clave batch con un desencadenador, como en este ejemplo:
trigger:
batch: true
branches:
include:
- main
Cuando se activa el desencadenador, Azure Pipelines garantiza que espera a que se complete cualquier ejecución de canalización activa. Después, inicia una nueva ejecución con todos los cambios acumulados desde la última ejecución.