Información sobre la validación de solicitudes de incorporación de cambios
Al usar solicitudes de incorporación de cambios, puede asegurarse de que otra persona revise las actualizaciones de las implementaciones de Azure. Pero normalmente resulta útil ejecutar comprobaciones automatizadas también en los cambios de código. En esta unidad, aprenderá a usar la validación y las comprobaciones automatizadas de las solicitudes de incorporación de cambios para aumentar la confianza del equipo en los cambios de código.
Validación de las solicitudes de incorporación de cambios
Al revisar una solicitud de incorporación de cambios para el código Bicep, puede que hayan algunos pasos que tienes que realizar para evaluar el cambio que son iguales. Entre estos pasos se pueden incluir los siguientes:
- Compruebe si el archivo de Bicep tiene errores o advertencias de linter.
- Asegurate de que los recursos definidos previamente en el archivo Bicep sigan funcionando.
- Pruebe los recursos recién definidos para asegurarse de que están implementados correctamente y de que funcionan según lo previsto.
La validación de la solicitud de incorporación de cambios implica la automatización de algunas de estas actividades. Al automatizar las comprobaciones de solicitudes de incorporación de cambios, los revisores pueden dedicar su tiempo a otros pasos de revisión más importantes, como asegurarse de que el código cumple los estándares de calidad del equipo y logra el objetivo empresarial.
En un flujo de trabajo de Acciones de GitHub, puede definir desencadenadores que invoquen el flujo de trabajo en determinados puntos durante el proceso de solicitud de incorporación de cambios, incluido el momento en que se crea, actualiza, combina o cierra una solicitud.
Prueba del código de Bicep en un flujo de trabajo de validación de solicitudes de incorporación de cambios
En módulos anteriores, has aprendido a crear flujos de trabajo de Acciones de GitHub completos para linting, la validación, la implementación y la prueba de los cambios en la infraestructura de Azure, incluso en varios entornos. Estos flujos de trabajo se ejecutan después de combinar los cambios en la rama principal.
También puedes ejecutar muchas de las mismas actividades en un flujo de trabajo de validación de solicitud de incorporación de cambios. Por ejemplo:
- Lintingtu código de Bicep hace que te puedas asegurar de que el código es semánticamente correcto y que sigue algunas prácticas de Bicep recomendadas como base de referencia.
- La validación previa a la comprobación ayuda a crear confianza en que el código se implementará correctamente, sin necesidad de implementar el archivo. Según el tipo de recurso, la validación previa a la comprobación puede buscar problemas como nombres de recursos no válidos, regiones no válidas para recursos específicos y si se ha especificado una configuración que no se puede implementar con éxito.
- Qué ocurre si se enumera los cambios que se realizarán en el entorno de Azure como resultado de la implementación.
- Implementaciones, para implementar realmente los recursos y asegurarse de que no hay errores de implementación.
- Probar los recursos después de la implementación para asegurarse de que están configurados según tus requisitos empresariales.
Un flujo de trabajo de validación de solicitudes de incorporación de cambios es un flujo de trabajo normal de Acciones de GitHub, por lo que puedes ejecutar cualquiera de estas tareas. Pero vale la pena pensar en los tipos de comprobaciones que tiene sentido ejecutar dentro de una solicitud de incorporación de cambios. Muchas de las actividades de validación enumeradas aquí requieren acceso a un entorno de Azure. Por ejemplo, la operación hipotética what-if compara los recursos definidos en los archivos Bicep con los de la suscripción de Azure. Es lógico ejecutar esta comparación en un entorno de producción, pero ya que presenta algún riesgo adicional, es posible que no le convenza ejecutar operaciones en un entorno de producción desde un flujo de trabajo diseñado para un código que aún no se ha completado o combinado.
En este módulo, agregarás dos tipos de comprobaciones al flujo de trabajo de validación de solicitudes de incorporación de cambios:
- Aplicar linting al código de Bicep para ejecutar un conjunto inicial de comprobaciones en él.
- Implementar el código en un entorno temporal nuevo.
Estas dos actividades no requieren conectarse al entorno de producción de Azure, ni siquiera a ninguno de los entornos normales que no son de producción, como el de prueba, el de control de calidad o el de almacenamiento provisional. Al ejecutar estas dos actividades, todavía puede aumentar la confianza en los cambios de código para poder combinarlos en la rama principal del repositorio.
Las comprobaciones son útiles para los revisores, ya que ahorran tiempo que, de lo contrario, se dedicaría a ejecutar las actividades manualmente. Las comprobaciones también son útiles para usted, como autor de la solicitud de incorporación de cambios, ya que puede usarlas para obtener una vista inicial de cómo funcionarán los cambios más adelante en el proceso de implementación.
En los flujos de trabajo de validación de solicitudes de incorporación de cambios, puedes optar por extender las comprobaciones de validación con actividades adicionales.
Desencadenadores del ciclo de vida de las solicitudes de incorporación de cambios
Una solicitud de incorporación de cambios en GitHub puede pasar por muchos y diferenteseventos de ciclo de vida. Por ejemplo, una solicitud de incorporación de cambios abierta. Después, el autor puede insertar cambios en la rama de origen y (sincronizar). Esto puede afectar al contenido de la solicitud de incorporación de cambios. Ahora la solicitud de incorporación de cambios puede combinarse o puedecerrarse sin combinarse e incluso reabrirse en el futuro.
Las Acciones de GitHub le permiten definir desencadenadores de flujo de trabajo que responden a cualquiera de estos eventos. Por ejemplo, puede definir un flujo de trabajo que se ejecute automáticamente cada vez que se abra, sincronice o vuelva a abrirse una solicitud de incorporación de cambios especificando el desencadenador pull_request sin ninguna configuración adicional:
on: pull_request
También puedes especificar eventos de solicitud de incorporación de cambios que desencadenen un flujo de trabajo. Por ejemplo, el siguiente flujo de trabajo se ejecuta automáticamente cada vez que se cierra una solicitud de incorporación de cambios:
on:
pull_request:
types: [closed]
Importante
Si hay conflictos de combinación en una solicitud de incorporación de cambios, el flujo de trabajo no se ejecutará. Debe resolver el conflicto e insertar la resolución para que el flujo de trabajo pueda ejecutarse.
Estado de comprobación de solicitud de incorporación de cambios
Los resultados de un flujo de trabajo de solicitud de incorporación de cambios se muestra en la página de detalles de la solicitud como comprobaciones. Las comprobaciones permiten a los autores y revisores obtener rápidamente comentarios sobre si las actividades automatizadas se han realizado correctamente o no, como en el ejemplo siguiente:
De manera predeterminada, incluso si se produce un error en una comprobación, se puede combinar la solicitud de incorporación de cambios. Es posible que no quieras permitir esto, por lo que puedes configurar lasreglas de protección de rama para aplicar que las comprobaciones específicas deben realizarse correctamente antes de que se pueda combinar una solicitud de incorporación de cambios.
Actualizando archivos
Después de crear una solicitud de incorporación de cambios, es habitual que un autor tenga que realizar actualizaciones. Por ejemplo:
- Un revisor puede ser que pida al autor que realice cambios en el código.
- Si se produce un error en una comprobación automatizada, el autor puede cambiar el código para corregir el problema y después confirmar e insertar los cambios.
Mediante el pull_requestdesencadenador, puedes configurar el flujo de trabajo de validación para que se ejecute cada vez que se actualice la rama de origen. Los resultados de la ejecución más reciente del flujo de trabajo se muestran en la página de detalles de la solicitud de incorporación de cambios.
Flujos de trabajo reutilizables
Si observa la lista de posibles comprobaciones para la validación de solicitudes de incorporación de cambios, verá que son los mismos pasos que se realizarían en el flujo de trabajo de implementación normal. Para evitar la repetición, es recomendable usar losflujos de trabajo reutilizables de GitHub.
Puede definir los flujos de trabajo reutilizables para cada uno de los trabajos que usará en diferentes definiciones de flujo de trabajo. Verá cómo hacerlo en el ejercicio siguiente.
Borrador de solicitudes de incorporación de cambios
Como autor, normalmente abriría una solicitud de incorporación de cambios cuando esté listo para que los cambios se revisen, aprueben y combinen. Pero puede resultar útil obtener acceso a las comprobaciones de validación de solicitudes de incorporación de cambios automatizadas durante todo el proceso de escritura del código, incluso si los cambios aún no están listos para combinarse.
Al abrir una solicitud de incorporación de cambios en GitHub, puedes marcarla como borrador. GitHub ejecuta todas las mismas comprobaciones automatizadas y los revisores todavía pueden proporcionar comentarios. Sin embargo, cuando la solicitud de incorporación de cambios está en estado de borrador, es claro para todos los usuarios que el trabajo aún no está listo para una revisión completa y no se puede combinar.
Es muy habitual crear borradores de solicitudes de incorporación de cambios cuando el flujo de trabajo de validación de solicitudes crea entornos efímeros, ya que puedes previsualizar los cambios en un entorno de trabajo en directo. A medida que sigues insertando los cambios, el entorno efímero se actualiza para incorporar los últimos cambios.