Ejercicio de colaboración en Azure Repos utilizando pull requests
Los problemas de código que se encuentran antes son más fáciles y más baratos de corregir. Por lo tanto, los equipos de desarrollo se esfuerzan por incorporar las comprobaciones de calidad del código lo más temprano posible en el proceso de desarrollo.
Como sugiere el nombre, las políticas de ramas proporcionan un conjunto de políticas integradas que puedes aplicar a las ramas del servidor.
Los cambios que se insertan en las ramas del servidor deben seguir estas directivas antes de que se puedan aceptar los cambios.
Las políticas son una excelente manera de aplicar los estándares de calidad del código y de gestión de cambios de tu equipo. En esta receta, aprenderá a configurar políticas de ramas en tu rama principal.
Preparándose
Las políticas de ramificación predeterminadas incluyen varias directivas, como la validación de compilación y la aplicación de una estrategia de combinación. Solo nos centraremos en las directivas de rama necesarias para configurar un flujo de trabajo de revisión de código en esta receta.
Cómo hacerlo
Abra la vista de ramas del repositorio de Git myWebApp en el portal del equipo Parts Unlimited. Seleccione la rama principal y, en el menú contextual desplegable, elija Directivas de rama:
En la vista de directivas, presenta directivas integradas. Establezca el número mínimo de revisores en 1:
La opción Permitir a los solicitantes aprobar sus propios cambios permite al remitente aprobar automáticamente sus cambios.
Aunque esto puede ser aceptable para los equipos maduros, en general, se debe evitar.
Use la directiva de revisión con la directiva de resolución de comentarios. Permite exigir que los comentarios de revisión de código se resuelvan antes de que se acepten los cambios. El solicitante puede tomar la retroalimentación del comentario, resolver los cambios y crear un nuevo elemento de trabajo. Al menos garantiza que los comentarios de revisión de código no se pierdan con la aceptación del código en la rama principal:
Un requisito instiga un cambio de código en el proyecto de equipo. Si el elemento de trabajo que desencadenó el trabajo no está vinculado al cambio, resulta difícil entender por qué se realizó a lo largo del tiempo. Es especialmente útil al revisar el historial de cambios. Configura la directiva Comprobar elementos de trabajo vinculados para bloquear los cambios que no tengan un elemento de trabajo vinculado.
Seleccione la opción para incluir automáticamente a los revisores cuando se genere automáticamente una solicitud de incorporación de cambios. Puede asignar qué revisores se agregan en función del área del código que se va a cambiar:
Cómo funciona
Con las directivas de rama en vigor, la rama principal ahora está totalmente protegida.
La única manera de insertar cambios en la rama principal es realizar primero los cambios en otra rama y, a continuación, generar una solicitud de incorporación de cambios para desencadenar el flujo de trabajo de aceptación de cambios.
Elija crear una nueva rama a partir de una de las historias de usuario existentes en el centro de elementos de trabajo.
Al crear una rama a partir de un elemento de trabajo, ese elemento de trabajo se vincula automáticamente a la rama.
Opcionalmente, puede incluir más de un elemento de trabajo con una rama como parte del flujo de trabajo de creación:
Prefije el nombre al crear la rama para crear una carpeta donde irá la rama.
En el ejemplo anterior, la rama irá en carpeta. Es una excelente manera de organizar ramas en entornos ocupados.
Con la rama recién creada seleccionada en el portal web, edite el archivo HomeController.cs para incluir el siguiente fragmento de código y confirmar los cambios en la rama.
En la imagen siguiente, verá que puede confirmar directamente los cambios después de editar el archivo haciendo clic en el botón confirmar.
El control de ruta de acceso de archivo en el portal del equipo admite la búsqueda.
Empiece a escribir la ruta de acceso del archivo para ver todos los archivos del repositorio de Git en ese directorio, empezando por estas letras que se muestran en la lista desplegable de resultados de búsqueda de la ruta de acceso de archivo.
El editor de código del portal web tiene varias características nuevas en Azure DevOps Server, como la compatibilidad con la coincidencia de corchetes y la alternancia de espacios en blanco.
Puede cargar la paleta de comandos presionando. Entre muchas otras opciones nuevas, ahora puede alternar la vista del archivo mediante un mini mapa de archivos, contraer y expandir, y realizar las otras operaciones estándar.
Para insertar estos cambios desde la nueva rama en la rama principal, cree una solicitud de incorporación de cambios desde la vista de solicitud de incorporación de cambios.
Seleccione la nueva rama como origen y principal como rama de destino.
El nuevo formulario de solicitud de incorporación de cambios admite Markdown, por lo que puede agregar la descripción mediante la sintaxis de Markdown.
La ventana de descripción también admite @ menciones y # para vincular elementos de trabajo:
Se crea la solicitud de incorporación de cambios; En la página de información general se resumen los cambios y el estado de las directivas.
La pestaña Archivos muestra una lista de cambios y la diferencia entre las versiones anteriores y actuales.
Las actualizaciones insertadas en los archivos de código se mostrarán en la pestaña Actualizaciones y se mostrará una lista de todas las confirmaciones en la pestaña Confirmaciones:
Abra la pestaña Archivos: esta vista admite comentarios de código en el nivel de línea, el nivel de archivo y en general.
Los comentarios admiten @ para menciones y # para vincular elementos de trabajo y el texto admite la sintaxis markdown:
Los comentarios de código se conservan en el flujo de trabajo de pull request; los comentarios de código admiten múltiples iteraciones de revisiones y funcionan bien con respuestas anidadas.
La directiva de revisor permite un flujo de trabajo de revisión de código como parte de la aceptación del cambio.
Es una excelente manera de colaborar en cualquier cambio de código insertado en la rama principal.
Cuando el número necesario de revisores aprueba la solicitud de incorporación de cambios, se puede completar.
También puede marcar la solicitud de incorporación de cambios para autocompletar una vez revisada. Completa automáticamente los pull requests una vez que todas las políticas se han aplicado correctamente.
Hay más
¿Alguna vez ha estado en un estado en el que se ha eliminado accidentalmente una rama? No puede ser fácil averiguar lo que pasó.
Azure DevOps Server ahora admite la búsqueda de ramas eliminadas. Le ayuda a comprender quién lo eliminó y cuándo. La interfaz también permite volver a crear la rama.
Las ramas eliminadas solo se muestran si se buscan por su nombre exacto para reducir el ruido en los resultados de búsqueda.
Para buscar una rama eliminada, escriba el nombre de la rama completa en el cuadro de búsqueda de la rama. Devolverá cualquier rama existente que coincida con ese texto.
También verá una opción para buscar una coincidencia exacta en la lista de ramas eliminadas.
Si se encuentra una coincidencia, verá quién lo eliminó y cuándo. También se puede restaurar la rama. La restauración de la rama la recreará en el último commit al que apuntaba.
Sin embargo, no restaurará las directivas y los permisos.