🔷Azure DevOps — Pipelines i polítiques de branques

Al nostre article anterior, vam forjar les nostres armes: scripts PowerShell a punt per defensar la qualitat a Microsoft Fabric. Ara és el moment de portar la batalla al nostre dojo d’Azure DevOps. Configurarem la nostra Pipeline i les polítiques de branca perquè actuïn com a guardians automàtics del nostre codi.

La missió? Que la branca main sigui una fortalesa impenetrable: només el codi que superi totes les validacions es podrà fusionar. Per a la branca dev, aplicarem un control rigorós però amb flexibilitat: els errors s’assenyalaran, però el flux de desenvolupament podrà continuar si un supervisor ho aprova, mantenint l’agilitat.

🐙 Si fas servir GitHub en lloc d’Azure DevOps, consulta l’article específic de GitHub Actions i Branch Protection Rules.

Pas 1: Preparant la pipeline ado-pipe-build.yaml

Abans de configurar les polítiques de branca, necessitem una pipeline que executi els nostres scripts de validació. El fitxer 📄ado-pipe-build.yaml (a la 📁 carpeta pipelines del repositori) s’encarrega d’aquesta tasca.

Punts clau d’aquesta pipeline:

• 🎯 Activació selectiva: es dispara només amb Pull Requests a main i dev (trigger: none i secció pr), i únicament si es modifiquen fitxers en rutes crítiques de src (paths: include:).
• ⚙️ Execució completa: totes les tasques de script fan servir continueOnError: true per assegurar que s’executin totes les validacions, encara que alguna falli.
• 🔍Detecció d’errors: failOnStderr: true als scripts PowerShell marca la tasca com a fallida si aquests reporten problemes.
• 📊 Publicació de resultats (PublishTestResults@2): recull els fitxers XML de resultats (testResultsFiles: '**/*-results.xml'). S’executa sempre (condition: succeededOrFailed()). Important: el paràmetre failTaskOnFailedTests: true d’aquesta tasca marcarà la build com a fallida si hi ha tests erronis. Tanmateix, el bloqueig real del merge en una Pull Request el controlarem amb l’opció «Policy requirement» de les polítiques de branca.

Pas 2: Configurant una pipeline des d’un fitxer YAML existent

Un cop tenim el fitxer YAML preparat, configurarem la pipeline a Azure DevOps perquè es pugui executar automàticament amb cada Pull Request.

🔧 Creació de la pipeline a partir del fitxer YAML

Accedeix al mòdul de Pipelines:

• Al teu projecte d’Azure DevOps, ves a Pipelines al menú lateral.
• Fes clic al botó New pipeline (o Create Pipeline si és la teva primera pipeline).

Selecciona l’origen del codi:

• Selecciona Azure Repos Git (o el servei on tens el codi).
• Tria el repositori que conté el codi i el fitxer YAML.

Configura la pipeline:

• A la pantalla «Configure your pipeline», selecciona Existing Azure Pipelines YAML file.
• Al selector de fitxers, navega fins a la ruta on hi ha el fitxer YAML:
• Selecciona la branca (normalment main o dev).
• Navega fins a ado-pipe-build.yaml.
• Fes clic a Continue.

Revisa la pipeline:

• Azure DevOps mostrarà el contingut del fitxer YAML. Revisa que tot sigui correcte.
• Si cal fer algun ajust, el pots fer directament a l’editor.

Desa la pipeline:

• Fes clic al desplegable del costat de Run i selecciona Save.
• Posa un nom descriptiu a la pipeline, per exemple: ado-pipe-build.yaml.
• Opcionalment, pots afegir-hi una descripció que n’expliqui breument el propòsit.

Mira el vídeo a YouTube

🔄 Verificació de la configuració

Revisa la configuració general:

• Un cop desada, ves a la secció Edit de la pipeline.
• Comprova que els triggers i els paths estiguin ben configurats.

Comprova els permisos

A la pantalla principal de la pipeline, fes clic als tres punts (…) i selecciona Manage security.

Assegura’t que els equips rellevants tenen els permisos adequats:

• Build Administrators i Contributors han de poder editar la pipeline.
• Readers només han de poder veure’n els resultats.

Pas 3: Configurant les polítiques de branques a Azure DevOps

Amb la pipeline a punt, és hora d’establir les regles del joc per a les nostres branques.

Accés a les polítiques de branca:

• A Azure DevOps, ves a Project Settings > Repos > Repositories > selecciona el teu repo > Branch Policies.

I des d’aquí seleccionarem la branca que volem configurar

Tens l’opció d’aplicar aquestes polítiques a totes les branques de tots els repositoris del projecte.

Amb aquesta opció configures les polítiques per a totes les branques del projecte

1. Per a main i dev, fes clic als tres punts (...) i selecciona Branch policies.

Branca main: 🛡️ Màxima protecció

Aquí no hi ha marge per a l’error.

👥 Require a minimum number of reviewers: estableix 1–2 revisors. Aquí tens configuracions addicionals sobre qui pot aprovar o no els canvis. Per a aquest exemple activarem «Prohibit the most recent pusher from approving their own changes».

📋 Check for linked work items: aquesta configuració t’obliga a tenir vinculat un element del Board.

💬 Check for comment resolution: amb aquest check ens assegurarem que tots els comentaris que hàgim deixat a la Pull Request quedin resolts (o almenys marcats com a resolts).

✅ Build Validation (el que més ens interessa): afegeix una política fent servir la pipeline ado-pipe-build.

• Policy requirement: la clau! Posa-ho a Required. Si la build falla, la PR no es podrà completar.
• Display name: p. ex.: «Quality Gates Check (Main)».

Ens hauria de quedar una cosa així

🔍 Automatically include reviewers: aquí configurarem la persona responsable del desenvolupament perquè sigui ella qui doni l’ok final.

Branca dev: 🔄 Flexibilitat controlada

Validem, informem, però permetem avançar amb supervisió.

👤 Require a minimum number of reviewers: pots ser més flexible (p. ex.: 1 revisor). «Prohibit the most recent pusher from approving their own changes» continua sent recomanable.

✅ Build Validation: afegeix una política fent servir la pipeline ado-pipe-build.

• Policy requirement: la diferència! Posa-ho a Optional. La build s’executarà i mostrarà errors, però no bloquejarà el merge per si sola. La decisió final recau en els revisors.
• Display name: p. ex.: «Quality Check (Dev)».

🔍 Automatically include reviewers: aquí aquesta configuració agafa protagonisme: necessitem que una persona responsable decideixi si un desenvolupament amb errors passa o no a la fase següent.

Sí, aquí tens el vídeo d’aquesta part :)

Mira el vídeo a YouTube

🚀 El teu control de qualitat a Azure DevOps ja està a punt!

I això és tot! Amb aquests passos, has transformat Azure DevOps en un sistema robust que no només executa automàticament les teves validacions de qualitat, sinó que també aplica diferents nivells d’exigència a les branques main i dev. Has posat les bases per a un desenvolupament més segur, consistent i àgil.

Ara cada Pull Request se sotmetrà a un escrutini digne dels déus ⚡, assegurant que només el codi de més qualitat arribi a producció, mentre mantens la flexibilitat que necessites als entorns de desenvolupament.