A menudo, como parte de la verificación de Solicitud de extracción, además de la revisión del código en sí, es necesario realizar un conjunto de verificaciones de rutina. Algunas verificaciones pueden referirse al diseño de relaciones públicas. Otros: verifique las condiciones relacionadas que forman la base del proceso de adopción de cambios.
Si los controles de rutina no están automatizados, una persona puede comenzar a olvidarlos o eludirlos. Porque la rutina es aburrida.
Visual Studio Team Services ofrece una infraestructura bastante conveniente para manejar la solicitud de extracción. Esto incluye políticas de compilación de fusión personalizadas, nombramiento de revisores, reglas de fusión para cambios aceptados. Todo esto se complementa con un sistema conveniente para discutir y comentar sobre el código.
La herramienta más poderosa para extender el proceso de solicitud de extracción son las políticas de complementos externos.
Hablaremos sobre su creación y uso (y ver el código)
Estados de solicitud de extracción expandibles
Los estados de relaciones públicas son indicadores definidos dentro del contexto. Contexto: una combinación única del nombre del contexto y el "género". El género suele ser uno por aplicación que manipula el estado.
Por ejemplo:
Estado 1: género = 'my-policy', nombre = 'check-1'
Estado 2: género = 'my-policy', nombre = 'check-2'
El estado toma uno de los valores predefinidos. Con el fin de apoyar el proceso, nos interesarán dos: exitoso y fallido.
Los estados se pueden usar al configurar una política de brunch: los indicadores seleccionados deben tener un estado exitoso para que se acepte PR. Del mismo modo, se implementan políticas integradas que verifican la cantidad de conductores, la presencia de un boleto adjunto, etc.
Vaya a editar la política de sucursal. Añadir política exterior.
Si el estado se ha configurado al menos una vez, estará disponible en el menú desplegable.
En la parte inferior, puede especificar un título para el estado, cómo se mostrará en el bloque de finalización de solicitud de extracción.
Los estados agregados serán visibles en la página de solicitud de extracción en el bloque de verificación:
Si el estado no se utiliza como política, su valor se muestra en la página en la sección Estado. Si el estado se especifica como una política, será visible en la parte superior del bloque.
Gestión del estado del programa
Los estados de relaciones públicas se pueden manipular mediante programación utilizando la API REST. Por lo tanto, es posible implementar comprobaciones de relaciones públicas adicionales y traducir sus resultados directamente en el proceso de realizar cambios.
El nuevo valor de estado se agrega mediante el método Crear . Además del resultado y el contexto, es necesario transmitir el texto que ve el usuario. Opcionalmente, puede pasar una URL: en este caso, la etiqueta de estado en el formulario PR se convertirá en un enlace y el usuario podrá ir a la página con los detalles del estado.
Una llamada al método da como resultado la creación de un nuevo registro de estado de relaciones públicas. Dentro de un contexto, el último valor de estado agregado se considera activo. Las entradas de estado anteriores no son visibles desde la interfaz de usuario, pero se pueden obtener utilizando el método de Lista .
Para el estado de los estados en la imagen anterior, la lista real de estados para la solicitud de extracción puede ser la siguiente:
{ "value": [ { "id": 1, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.0324172Z", "updatedDate": "2018-11-06T18:35:57.0324172Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 2, "state": "failed", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.5167963Z", "updatedDate": "2018-11-06T18:35:57.5167963Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 3, "state": "succeeded", "description": "No offset from develop", "context": "@{name=check-offset; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.782379Z", "updatedDate": "2018-11-06T18:35:57.782379Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 4, "state": "succeeded", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:46:37.2627154Z", "updatedDate": "2018-11-06T18:46:37.2627154Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 5, "state": "succeeded", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:51:33.7920543Z", "updatedDate": "2018-11-06T18:51:33.7920543Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 6, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:53:44.3075889Z", "updatedDate": "2018-11-06T18:53:44.3075889Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 7, "state": "failed", "description": "Title format is not correct", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T19:26:11.3019433Z", "updatedDate": "2018-11-06T19:26:11.3019433Z", "createdBy": "Masked value", "targetUrl": null } ], "count": 7 }
Después de mirar la lista de estados actuales, puede actualizar el seleccionado por índice en la lista. Para hacer esto, use el método Actualizar .
Finalmente, los registros de estado se pueden eliminar utilizando el método Eliminar .
Un historial de cambios en el estado de las relaciones públicas puede ser útil para un análisis posterior. Por lo tanto, utilizamos el siguiente método para cambiar estados:
- Encuentra el último registro de estado para el mismo contexto
- Si tiene los mismos valores de resultados, descripciones y enlaces que queremos agregar, no hacemos nada
- De lo contrario, agregue un nuevo registro de estado.
Esto le permite mantener un historial de cambios, sin inflarlo demasiado.
function Set-PullRequestStatus { param( [Parameter (Mandatory = $true)] [string] $pullRequestId, [Parameter (Mandatory = $true)] [string] $state, [Parameter (Mandatory = $true)] [string] $description, [Parameter (Mandatory = $true)] [string] $contextName, [Parameter (Mandatory = $false)] [string] $contextGenre, [Parameter (Mandatory = $false)] [string] $targetUrl, [Parameter (Mandatory = $true)] [object] $context ) $b = @{ state = $state; description = $description; context = @{ name = $contextName; genre = $contextGenre; }; targetUrl = $targetUrl; } $body = ConvertTo-Json $b # # Get current list of statuses # $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) # # Try to find a status for a given context genre and name. Start looking from the last one. If found - check if it has same values. # $i = $res.count $foundSameStatus = $false while ($i -GT 0) { $r = $res.value[$i-1] if (($r.context.name -EQ $contextName) -AND ($r.context.genre -EQ $contextGenre)) { $foundSameStatus = ($r.state -EQ $state) -AND ($r.description -EQ $description) -AND ($r.targetUrl -EQ $targetUrl) break } $i-- } $res = $r # # If same status / values was not found - add new record. # if (-not $foundSameStatus) { $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) -method POST -query $body } return @{status = $res; status_changed = $(-not $foundSameStatus)} }
Aplicación práctica
Hemos adoptado un enfoque bastante conservador para aceptar cambios en la rama de integración. Intentamos probar el cambio al máximo en la rama de la característica al máximo.
Estas son algunas de las tareas que resolvemos con la ayuda de los estados de relaciones públicas, como parte de las políticas personalizadas:
- Todos los RP deben estar decorados en el mismo estilo. Por lo tanto, el primer control que se creó es el diseño del encabezado PR. Lo comprobamos con la expresión regular.
- La rama PR no debe quedarse atrás de la rama donde se vierte (se lleva a cabo la integración).
- Si, dentro del marco de relaciones públicas, los archivos del proyecto de la base de datos se cambian, entonces los archivos de prueba automática también deben estar presentes.
- Hay un montaje exitoso de la sucursal para el último cambio.
- Esta asamblea se bombeó con éxito al banco de pruebas y se aprobaron las pruebas automáticas.
Las condiciones enumeradas se pueden verificar manualmente. Hicimos esto antes. Pero esta es una rutina, y ha sido reemplazada por un proceso automatizado. Ahora podemos complementar y cambiar el conjunto de comprobaciones: siempre se integrará en el proceso, siempre se ejecutará.
Una gran ventaja adicional de las políticas (son transparentes para todos y siempre están a la vista) en la página de relaciones públicas. Ya no necesitan que se les recuerde.
Además, para las políticas que fallan en la verificación, mostramos un enlace a nuestras páginas Wiki con una descripción de la política y las acciones esperadas.
Implementación técnica de aplicación de políticas
Actualmente, la lógica de la política se implementa en forma de scripts de PowerShell. Debido a los cmdlets de alto nivel y a un buen modelo de datos de objetos, el código del script es muy compacto. Y la capacidad de ejecutar el script de forma interactiva en pasos y modificar las variables, simplifica enormemente el proceso de desarrollo y depuración.
Por cierto, después del lanzamiento de powershell core, los scripts se pueden ejecutar en otras plataformas (probado en MacOS).
Ejecute los scripts en una versión especial de VSTS en un horario aproximadamente una vez cada dos horas. Tal vez comencemos a pasar por el programador con más frecuencia.
Este enfoque, por supuesto, proporciona una respuesta significativamente más lenta que si implementa lo mismo en forma de Azure Function y lo conecta a VSTS a través de un enlace web. Pero para nosotros fue más importante implementar controles y ver cómo funcionará esto en el proceso (MVP). La eficiencia de la verificación aún no es importante. Este será el siguiente paso.
La implementación de las bibliotecas para trabajar con la API REST de VSTS, que se utilizan en las comprobaciones, más un pequeño ejemplo que implementa algunas de estas políticas se puede encontrar en el repositorio en GitHub . Espero que alguien lo encuentre útil.