Automatizar la validación de pruebas antes de fusionar código a main es uno de los pasos más valiosos al implementar DevOps. Con un GitHub Action para pull requests puedes obligar a tu equipo a pasar una batería de pruebas antes de cualquier merge, blindando la calidad del proyecto desde el primer commit.

Este flujo te sirve si trabajas con .NET, manejas ramas protegidas y quieres que cada pull request dispare automáticamente la ejecución de tus tests sin depender de revisiones manuales superficiales.

¿Cómo configurar un workflow YAML para validar pull requests?

El primer paso ocurre dentro del repositorio, en la pestaña Actions, donde eliges crear un nuevo flujo de trabajo personalizado. Ahí GitHub genera un archivo YAML que en este caso se nombra pull_request_review.yml [0:30].

Dentro de ese archivo defines la lógica del workflow: cada vez que se abra un pull request apuntando a la rama main, la acción se dispara y corre las pruebas en un agente Ubuntu Latest [1:18].

¿Qué pasos debe tener el workflow?

La estructura del archivo YAML sigue una secuencia clara y replicable:

• Hacer checkout del código del repositorio.
• Configurar .NET en la versión 8, que es la versión de soporte de largo término [1:40].
• Restaurar dependencias apuntando al folder src como directorio de trabajo.
• Compilar el proyecto dentro de ese mismo directorio.
• Ejecutar dotnet test para correr las mismas pruebas que ya validaste localmente [2:05].

La lógica es simple: replicar en la nube el entorno de pruebas local para que ningún cambio entre a main sin haber pasado el filtro automatizado.

¿Qué hace un GitHub Action en un pull request? Ejecuta automáticamente tareas como compilar el código, correr pruebas o validar formato cada vez que alguien abre o actualiza un pull request. Si las pruebas fallan, el merge queda bloqueado.

¿Por qué guardar el workflow directo en main como administrador?

Aquí aparece un truco práctico: como administrador del repositorio puedes saltarte las reglas de protección y guardar el archivo directamente en main, sin abrir un pull request para tu propio workflow [2:40].

La razón es lógica. No tiene sentido pedirte a ti mismo una revisión para configurar las reglas que vas a aplicar al resto del equipo. Un contribuidor sin permisos de administrador no vería esta opción y tendría que seguir el flujo normal.

Una vez guardado, el workflow aparece en la sección Actions como Run test on pull request, listo para evaluar cualquier rama que intente entrar a partir de ese momento.

¿Cómo se comporta el flujo cuando abres un pull request real?

Al hacer un cambio simple, por ejemplo eliminar un comentario en program.cs, haces commit, sincronizas y abres un pull request desde GitHub [3:50]. El sistema detecta de inmediato que falta una review requerida y dispara la action configurada.

En segundos verás los checks corriendo. Cuando las pruebas pasan, aparece la luz verde y el pull request queda habilitado para revisión humana.

¿Cómo acelerar los code reviews con Copilot y closes?

Dos prácticas se combinan aquí para reducir tiempos muertos:

• Asignar a Copilot como primer revisor para que analice el código antes que un humano y marque comentarios automáticos [4:50].
• Editar la descripción del pull request y agregar la palabra clave closes #número para vincularlo con un issue existente [5:30].

Con closes #1, por ejemplo, cuando el pull request se fusione, ese issue se cerrará automáticamente y la tarea se moverá sola en el tablero del proyecto.

¿Qué significa LGTM en un code review? Es la abreviatura de looks good to me. Es la forma corta y amistosa de decir que revisaste el código y todo está en orden para fusionar.

¿Qué beneficios de DevOps se ven en este flujo?

Cuando el revisor aprueba con un comentario tipo LGTM, los checks ya pasaron, no hay conflictos y puedes ejecutar Confirm merge sin fricción [6:20]. Después eliminas la rama, que ya cumplió su propósito.

Lo interesante es lo que ocurre sin que tengas que hacer nada más:

1. El pull request se cierra al fusionarse.
2. El issue asociado se cierra automáticamente gracias a closes.
3. La tarea en el tablero del proyecto pasa de in progress a done sin intervención manual.

Este encadenamiento es lo que da visibilidad real al project manager. Puede ver con qué velocidad se cierran los issues, medir la eficiencia del equipo durante el sprint y detectar cuellos de botella sin perseguir a nadie por Slack.

La magia no está en una sola herramienta, sino en cómo el workflow YAML, las ramas protegidas, los issues vinculados y el tablero de proyecto se conectan en una misma cadena automatizada. Ese es el primer gran beneficio tangible de adoptar DevOps en tu día a día.

¿Ya tienes un workflow similar en tu repositorio o estás por crear el primero? Cuéntame en los comentarios qué parte del flujo te genera más dudas.