Las políticas de branch dentro de Azure DevOps son junto con la seguridad las dos maneras de evitar que código no revisado o sin autorización pueda ingresar dentro de tu rama principal protegiendo tu producto de estos problemas.
Políticas en tus branches
En tu portal de Azure navega a la página de Repos. Una vez ahí, selecciona la categoría de Branches podrás ver en esa sección todas las ramas con las que cuenta tu repositorio.
De aquí en adelante es necesario decir que solo podrás avanzar y modificar las cosas únicamente si tienes permiso para ello. Asumiré que si puedes así que podemos continuar. Selecciona a la derecha de cada rama los tres puntos que aparecen ahí y elige la opción de Branch policies.
En esta sección podrás ver cuatro categorías:
- Políticas de la rama.
- Validación para un Build.
- Revisiones de estado.
- Verificadores automáticamente incluidos.
Vamos por partes:
Branch policies (políticas de la rama): Aquí es donde quizá vas a trabajar la mayor cantidad de veces para poder establecer políticas.
Activar la primera política, la política de requerir un número mínimo de revisadores es quizá la más conocida, sirve para que si alguien quiere agregar algo a la rama principal entonces debe crear un Pull Request (PR) y un punto para su aprobación es que debe contar con un minimo de aprobación de quienes lo revisan. Como se muestra en la imagen de abajo, puedes elegir el número mínimo, también puedes permitir que quien crea el Pull Request pueda aprobar, esto no es una buena idea, como tampoco prohibir al último generador de contenido aprobarse. La tercera opción es para aprobar un Pull Request incluso si alguien lo rechazó y por último la opción final es muy buena, si hay cambios después de que el PR haya sido aprobado entonces estos votos se resetearán para volver a solicitarlos.
Build validation
Al habilitarla, esta directiva evalúa el resultado de un nuevo build cada vez que un nuevo PR es creado o si hay cambios en un PR existente. Si la compilación de esta rama no es exitosa, entonces el PR no podrá ser completado.
Para agregar una validación, primero, necesitamos crear un nuevo pipeline en la sección de pipelines.
Con este nuevo recurso creado, regresa a la página de configuración de las ramas y agrega el nuevo pipeline en la sección mencionada.
Con la política ya hecha, será visible dentro de la sección de validación. Puedes también agregar nuevas opciones, modificar la que ya tienes o eliminarla. Habilitar la opción es requerido para lanzar el pipeline de manera automática.
Status check
Esta política es por mucho la que menos uso, te permite agregar sericios de terceros para incluirlos en el proceso y basarte en políticas externas. Francamente, hasta ahora la he usado solo una vez y no resulto muy bien, generaba mas lentitud que ayuda.
Reviewer policy
Otra divertida, te permite automáticamente incluir a algunos revisadores para cada PR basado en ciertas rutas, esto te ahorra un gran dolor de cabeza al evitar recordar o asignar a quien debe revisarte, en equipos grandes esto es una gran herramienta.
Aquí tienes dos opciones para agregar a miembros de tu equipo: Opcionales y Requeridos así como el establecimiento de la ruta que vas a utilizar.
Hasta aquí, tienes ya un abanico completo de posibilidades para poder desplegar muchas directivas pero únicamente para una sola rama, la que hayas elegido para trabajar. Si quieres hacer esto para todas las ramas, únicamente debes hacerlo desde la configuración del proyecto.
De esta manera es que podrás trabajar con las políticas de uso de tus ramas y gracias a ello evitar que tu rama principal se vea afectada por cosas que no deseas que pasen tan fácilmente.