Hasta donde sé, la mejor manera de tener una construcción de rama condicional es usar "trigger" en su YAML, en lugar de implementar "if-else" complejo. También es mucho más seguro y tiene controles más explícitos sobre los desencadenantes de la rama en lugar de depender de las variables de CI.
Ejemplo:
# specific branch build
jobs:
- job: buildmaster
pool:
vmImage: 'vs2017-win2016'
trigger:
- master
steps:
- script: |
echo "trigger for master branch"
- job: buildfeature
pool:
vmImage: 'vs2017-win2016'
trigger:
- feature
steps:
- script: |
echo "trigger for feature branch"
Para tener un activador con inclusión y exclusión de ramas, puede usar una sintaxis más compleja de activador con incluir y excluir ramas.
Ejemplo:
# specific branch build
trigger:
branches:
include:
- master
- releases/*
exclude:
- releases/1.*
La documentación oficial de Azure DevOps Pipelines trigger
en YAML es:
Documentación de activación de Azure Pipelines YAML
ACTUALIZACIÓN 1 :
Vuelvo a publicar mi comentario aquí con notas adicionales: estaba pensando en tener diferentes canales porque tener la complejidad de hacer malabarismos entre las variables de CI no es más fácil de mantener que tener múltiples trabajos en un YAML con disparadores. Tener múltiples trabajos con disparadores también nos obliga a tener una clara distinción y provisión en la gestión de sucursales. Mi equipo ha utilizado disparadores e inclusiones de ramas condicionales durante un año debido a estas ventajas de mantenibilidad.
No dude en estar en desacuerdo, pero para mí tener una lógica incrustada en cualquier secuencia de comandos en cualquier paso para verificar qué rama está actualmente en sesión y luego realiza cualquier otra acción, son más como soluciones ad-hoc. Y esto nos ha dado a mi equipo y a mí problemas de mantenimiento antes.
Especialmente si la lógica incrustada tiende a crecer comprobando otras ramas, la complejidad es más compleja más tarde que tener claras separaciones entre ramas. Además, si el archivo YAML se va a mantener durante mucho tiempo, debe tener disposiciones claras y hojas de ruta en diferentes ramas. La redundancia es inevitable, pero la intención de separar la lógica específica pagará más a largo plazo por la mantenibilidad.
Es por eso que también enfatizo las inclusiones y exclusiones de ramas en mi respuesta :)