🔷Azure DevOps — Pipelines y políticas de ramas

---

En nuestro artículo anterior, forjamos nuestras armas: scripts PowerShell listos para defender la calidad en Microsoft Fabric. Ahora, es el momento de llevar la batalla a nuestro dojo de Azure DevOps. Vamos a configurar nuestra Pipeline y la políticas de rama para que actúen como guardianes automáticos de nuestro código.

¿La misión? Que la rama main sea una fortaleza impenetrable: solo el código que supere todas las validaciones podrá fusionarse. Para la rama dev, aplicaremos un control riguroso pero con flexibilidad: los errores se señalarán, pero el flujo de desarrollo podrá continuar si un supervisor lo aprueba, manteniendo la agilidad.

🐙Si utilizas GitHub en lugar de Azure DevOps, consulta el artículo específico para GitHub Actions y Branch Protection Rules.

Paso 1: Preparando la Pipeline ado-pipe-build.yaml

Antes de configurar las políticas de rama, necesitamos una pipeline que ejecute nuestros scripts de validación. El archivo 📄ado-pipe-build.yaml (ubicado en la 📁 carpeta pipelines del repositorio) se encarga de esta tarea.

Puntos clave de esta pipeline:

• 🎯 Activación selectiva: Se dispara solo con Pull Requests a main y dev (trigger: none y sección pr), y únicamente si se modifican archivos en rutas críticas de src (paths: include:).
• ⚙️ Ejecución completa: Todas las tareas de script usan continueOnError: true para asegurar que se ejecuten todas las validaciones, incluso si alguna falla.
• 🔍Detección de errores: failOnStderr: true en los scripts PowerShell marca la tarea como fallida si estos reportan problemas.
• 📊 Publicación de resultados (**PublishTestResults@2**): Recoge los archivos XML de resultados (testResultsFiles: '**/*-results.xml'). Se ejecuta siempre (condition: succeededOrFailed()). Importante: El parámetro failTaskOnFailedTests: true en esta tarea marcará la build como fallida si hay tests erróneos. Sin embargo, el bloqueo real del merge en un Pull Request lo controlaremos con la opción “Policy requirement” en las Políticas de Rama.

Paso 2: Configurando una Pipeline desde un archivo YAML existente

Una vez que tenemos nuestro archivo YAML preparado, vamos a configurar la pipeline en Azure DevOps para que pueda ejecutarse automáticamente con cada Pull Request.

🔧 Creación de la pipeline a partir del archivo YAML

Accede al módulo de Pipelines:

• En tu proyecto de Azure DevOps, navega a Pipelines en el menú lateral.
• Haz clic en el botón New pipeline (o Create Pipeline si es tu primera pipeline).

Selecciona el origen del código:

• Selecciona Azure Repos Git (o el servicio donde está almacenado tu código).
• Elige el repositorio que contiene tu código y el archivo YAML.

Configura tu pipeline:

• En la pantalla “Configure your pipeline”, selecciona Existing Azure Pipelines YAML file.
• En el selector de archivos, navega hasta la ruta donde se encuentra tu archivo YAML:
• Selecciona la rama (normalmente main o dev).
• Navega hasta ado-pipe-build.yaml.
• Haz clic en Continue.

Revisa tu pipeline:

• Azure DevOps mostrará el contenido de tu archivo YAML. Revisa que todo esté correcto.
• Si necesitas realizar algún ajuste, puedes hacerlo directamente en el editor.

Guarda tu pipeline:

• Haz clic en el botón desplegable junto a Run y selecciona Save.
• Proporciona un nombre descriptivo para tu pipeline, por ejemplo: ado-pipe-build.yaml.
• Opcionalmente puedes añadir una descripción que explique brevemente su propósito.

Ver el vídeo en YouTube

🔄 Verificación de la configuración

Revisa la configuración general:

• Una vez guardada, ve a la sección de Edit de tu pipeline.
• Verifica que los triggers y paths están configurados correctamente.

Comprueba los permisos

En la pantalla principal de tu pipeline, haz clic en los tres puntos (…) y selecciona Manage security.

Asegúrate de que los equipos relevantes tienen los permisos adecuados:

• Build Administrators y Contributors deben tener permisos para editar la pipeline.
• Readers solo deben tener permisos para ver los resultados.

Paso 3: Configurando las políticas de ramas en Azure DevOps

Con la pipeline lista, es hora de establecer las reglas del juego para nuestras ramas.

Acceso a las Políticas de Rama:

• En Azure DevOps, navega a Project Settings > Repos > Repositories > Seleccionas tu repo > Branch Policies.

Y desde aquí seleccionaremos la rama en la que queremos realizar la configuración

Tienes la opción de aplicar estas políticas a todas las ramas de todos los repositorios de tu proyecto.

Con esta opción configuras las políticas para todas las ramas del proyecto

1. Para main y dev, haz clic en los tres puntos (...) y selecciona Branch policies.

Rama **main**: 🛡️ Máxima protección

Aquí no hay margen para el error.

👥 Require a minimum number of reviewers: Establece 1–2 revisores. Aquí tienes configuraciones adicionales relacionadas sobre quien puede aprobar o no los cambios. Para este ejemplo activaremos “Prohibit the most recent pusher from approving their own changes” .

📋 Check for linked work items: Esta configuración te obliga a tener un elemento del Board vinculado.

💬 Check for comment resolution: Con este check nos aseguraremos que todos los comentarios que hayamos dejado en el Pull Request queden completados (o almenos marcados como completados).

✅ Build Validation (lo que más nos interesa): Añade una política usando tu pipeline ado-pipe-build.

• Policy requirement: ¡La clave! Establécelo en Required. Si la build falla, el PR no se podrá completar.
• Display name: Ej: “Quality Gates Check (Main)”.

Nos debería quedar algo así

🔍 Automatically include reviewers: Aquí configuraremos a la persona responsable del desarrollo para que ella de el ok final.

Rama **dev**: 🔄 Flexibilidad controlada

Validamos, informamos, pero permitimos avanzar con supervisión.

👤 Require a minimum number of reviewers: Puedes ser más flexible (ej: 1 revisor). “Prohibit the most recent pusher from approving their own changes” sigue siendo recomendable.

✅ Build Validation: Añade una política usando tu pipeline ado-pipe-build.

• Policy requirement: ¡La diferencia! Establécelo en Optional. La build se ejecutará y mostrará errores, pero no bloqueará el merge por sí misma. La decisión final recae en los revisores.
• Display name: Ej: “Quality Check (Dev)”.

🔍 Automatically include reviewers: Esta configuración aquí coge protagonismo, necesitamos que, una persona responsable sea la que decida si pasa a la siguiente fase o no un desarrollo con errores.

Sí, aquí va tu video de esta parte :)

Ver el vídeo en YouTube

🚀 ¡Tu control de calidad en Azure DevOps está listo!

¡Y eso es todo,! Con estos pasos, has transformado Azure DevOps en un sistema robusto que no solo ejecuta tus validaciones de calidad automáticamente, sino que también aplica diferentes niveles de exigencia a tus ramas main y dev. Has sentado las bases para un desarrollo más seguro, consistente y ágil.

Ahora, cada Pull Request será sometido a un escrutinio digno de los dioses ⚡, asegurando que solo el código de la más alta calidad llegue a producción, mientras mantienes la flexibilidad necesaria en tus entornos de desarrollo.