En este artículo hablaremos de Azure DevOps (anteriormente Visual Studio Team Services) y veremos cómo podemos implementarlo durante el proceso de ‘pull request’ para seguir tanto las políticas de calidad del código ya establecidas como las adicionales de cada equipo.
Integrarse en el flujo de trabajo de relaciones públicas implica conocer los conceptos y procedimientos que os detallamos a continuación.
1. ¿Qué es un pull request?
«Pull request» significa «Petición de validación». Simplificándolo al máximo, un pull request es la acción de someter a validación un código que va a fusionarse (o hacer un ‘merge’, como se suele decir en el mundo de la informática) de una rama a otra. En otras palabras, los pull requests son un mecanismo para que los desarrolladores notifiquen a los miembros de su equipo que han terminado de aplicar un/os cambio/s. Así, los pull requests ofrecen un espacio de debate donde todas las personas involucradas en el proyecto pueden discutir los cambios propuestos y revisar el código antes de fusionarlo con la rama master (o lo que es lo mismo, integrarlo en el proyecto). En este proceso de validación pueden entrar los factores que queramos: ‘builds’ (validaciones automáticas), validaciones manuales, etc.
2. Service Hooks
Cualquier servicio que se desee integrar con pull request necesitará saber cuándo se ha creado o actualizado un nuevo ‘pull request’, de modo que se pueda evaluar el contenido del mismo. Los ‘service hooks’ permiten alertar a los sistemas externos cada vez que ocurre un evento en Azure DevOps.
Hay dos activadores de eventos para un pull request:
- Pull request
- Pull request actualizado
Debemos asegurarnos de que haya suscripciones para ambos eventos para poder recibir notificaciones cada vez que cambie el código en un pull request.
3. Estado del pull request
La calidad del código durante el proceso de pull request es impuesta por las políticas de ‘branches’ que hayamos definido previamente. Estas políticas permiten a los equipos implementar mejores prácticas relacionadas con la revisión del código y la ejecución de ‘builds’ automáticas, pero muchos equipos tienen requisitos y validaciones adicionales para cumplir con el código. Para cubrir estas necesidades individuales y personalizadas, Azure DevOps ofrece estados de pull request, los cuales se integran en el flujo de trabajo y permiten que los servicios externos desactiven programáticamente un cambio de código asociando información simple de tipo éxito/fallo a un pull request (opcionalmente, los pull requests se pueden bloquear hasta que el servicio externo apruebe el cambio, como veremos en el siguiente apartado).
En resumen, el estado permite que los servicios asocien la información de éxito/fallo a un pull request utilizando una API de estado. Básicamente, el estado es la forma en que un usuario o servicio publica su evaluación sobre un pull request, permitiendo saber si los cambios acometidos cumplen o no con los requisitos y, en caso de que no los cumplan, qué hay que hacer para que así sea.
Un estado consta de cuatro datos clave:
- Estado: Aquí aparecen valores como ‘Succeded’, ‘failed’, ‘pending’, ‘notSet’, ‘notAplicable’ o ‘error’.
- Descripción: Aporta una cadena que describe el estado para el usuario final.
- Contexto: Proporciona un nombre para el estado, describiendo por norma general la entidad que publica el estado.
- URL: Provee un enlace a través del cual los usuarios pueden obtener información específica del estado.
4. Políticas de estado
A veces, compartir información sobre un pull request es todo lo que se requiere para la finalización del mismo, pero en otros casos se debe evitar que los pull requests se fusionen hasta que se cumplan los requisitos. La política de estado supone un mecanismo para bloquear la finalización del pull request hasta que el estado del mismo indique «succeeded».
En resumen, las políticas de estado proporcionan una vía para que los servicios externos bloqueen la finalización de relaciones públicas hasta que se cumplan los requisitos. Hay dos tipos de política de estado:
- Obligatoria: Para completar el pull request, debe aprobarse con el estado «succeeded».
- Opcional: Es sólo informativo y no se requiere el estado «succeeded» para completar el pull request.
Las políticas de estado se configuran como otras políticas de ‘branches’. Al agregar una nueva política de estado, se debe ingresar el nombre y el género de la política de estado. Si el estado ha sido publicado anteriormente, se puede seleccionar de la lista. Si es una política nueva, puede escribirse el nombre de la política con el formato género/nombre.
Cuando se especifica una política de estado, se requiere lo siguiente para que dicha política sea correcta:
- Un estado «succeeded»
- Que el campo «Context» coincida con el nombre seleccionado
También se puede seleccionar una cuenta autorizada para establecer que una cuenta específica tenga la autoridad para publicar el estado que aprobará la política.
5. Aplicación de la política de estados
Las opciones de aplicación de la política de estados de un pull request determinan si una política se aplica tan pronto como se crea un pull request o no y si se utiliza o no después de que se publique el primer estado en el pull request.
La aplicación de una política de pull request se puede llevar a cabo de dos formas:
- Predeterminada: Con esta opción, la política no se lanza después de la creación de un pull request, sino que lo hace cuando el estado es «succeeded». Un pull request se puede marcar como exento de la política publicando un estado de «notApplicable» que eliminará el requisito de política.
- Condicional: La política se aplica en el momento en que se publica el primer estado en el pull request.
Combinadas, estas opciones se pueden utilizar para crear un conjunto de políticas dinámicas. Se puede configurar una política de orquestación de alto nivel para que se aplique de forma predeterminada mientras se evalúa el pull request para las políticas aplicables. Luego, a medida que se determinan las políticas condicionales adicionales para su aplicación (tal vez en función de un resultado de compilación específico), el estado se puede publicar para que sean necesarias. Esta política de orquestación podría marcarse como «succeeded» cuando finalizase la evaluación o podría marcarse como «notApplicable» para indicarle al pull request que la política no se aplica.
6. Acciones personalizadas
Además de los eventos predefinidos de enganche de servicio que se pueden activar, es posible ampliar el menú de estado mediante el uso de extensiones de Azure DevOps y permitir acciones de activación al usuario final. Por ejemplo, si el estado corresponde a la ejecución de una prueba que puede ser reiniciada por el usuario final, es posible tener la opción de menú «Reiniciar en el menú de estado» que activaría la ejecución de las pruebas.
Se debe hacer uso del modelo de contribución para poder agregar un menú de estado. En la guía de Contribuciones de Github podréis ver las partes del código que agregan los siguientes elementos de muestra al menú de estado:
7. Finalización automática de work items con pull request
Al vincular un ‘work item’ a un pull request, se tiene la opción de completar automáticamente esos work items cuando el pull request se completa con éxito («suceeded»). Tal y como se muestra en la siguiente imagen, todo lo que se tiene que hacer es marcar la casilla para completar los work items vinculados después del ‘merge’, por lo que, a partir de entonces, el sistema predeterminaría su selección para futuros pull requests.
Si queréis comentarnos lo que sea podéis hacerlo en info@kabel.es
