Merge requests y control de calidad en GitLab

Los merge requests son la puerta de entrada a producción en un entorno DevOps. Aquí se decide, con datos y evidencia, si un cambio va a integrarse al branch principal y si cumple estándares de calidad, seguridad y rendimiento. Entender su flujo en GitLab y mantenerlos atómicos es clave para liberar con confianza.

¿Por qué los merge requests deciden calidad, seguridad y negocio en DevOps?

Un merge request reúne la información que permite tomar decisiones informadas antes de integrar a master. Debe responder si el cambio resuelve el issue, si añade riesgos y cómo impacta al sistema.

• Validar que el cambio resuelve el issue asignado.
• Confirmar que el código es correcto.
• Detectar vulnerabilidades nuevas al escanear dependencias.
• Evaluar si el performance se degrada tras el cambio.
• Revisar nuevas dependencias y sus licencias.

Las licencias importan para el modelo de negocio. Existen licencias abiertas que obligan a que tu código también sea abierto y gratuito; si buscas cobrar, vender licencias o generar regalías, una licencia así puede impedirlo. Identificarlo en el merge request evita problemas futuros.

En GitLab, los merge requests muestran widgets clave:

• Estado del pipeline de tests automatizados.
• Reporte de performance (por ejemplo, “se degradó en un punto”).
• Resultados de seguridad por el escaneo de dependencias.

¿Por qué deben ser atómicos y pequeños los merge requests?

Los merge requests grandes con cientos de archivos son casi imposibles de revisar a fondo. Suele ocurrir que se aprueban sin análisis profundo o se rechazan por tamaño. En cambio, los cambios atómicos permiten:

• Revisión técnica detallada y oportuna.
• Sugerencias de mejora antes de llegar a producción.
• Trazabilidad clara del efecto de cada cambio.

¿Cómo es el flujo de trabajo de merge requests en GitLab?

El flujo es sencillo y transparente para todo el equipo. Iniciar un merge request al comienzo del trabajo es una práctica recomendada para dar visibilidad y permitir seguimiento desde el día uno.

• Ir a Issues y cerrar con comentario que explique el motivo del cierre.
• Mover la tarjeta en el board a doing cuando se empieza a trabajar.
• Crear un merge request de inmediato junto con su branch para exponer el progreso.
• Usar el prefijo W I P en el título. Significa work in progress y GitLab bloqueará el merge mientras esté presente.
• Copiar el nombre del branch para trabajar en local y verificar en el repositorio si ya hay cambios.

¿Qué significa WIP en GitLab y cómo bloquea el merge?

El prefijo WIP indica que el trabajo sigue en curso. Mientras el título tenga WIP, GitLab prohibirá fusionar, evitando integrar algo incompleto. Así, revisores y responsables saben que deben esperar antes de evaluar la integración.

¿Qué comandos y estructura se aplicaron para crear issue templates?

Para avanzar con las plantillas de issues, se comenzó desde la línea de comandos, sincronizando y creando el branch, y luego editando la estructura en el editor.

Comandos usados en consola:

git pull
git branch
# Crear el branch local que seguirá al remoto (nombre de ejemplo):
# uno-crear-issue-templates-para-books
git checkout uno-crear-issue-templates-para-books

Estructura de carpetas y archivo para plantillas en GitLab:

.gitlab/
  issue templates/
    bug md

Contenido simple para la plantilla de bug, combinando indicaciones en español e inglés para claridad del reporte:

Summary / Resumen
Da el resumen del issue.

Steps to reproduce
Indica los pasos para reproducir el bug.

What is the current behavior?
¿Cuál es el comportamiento actual?

What is the expected behavior?
¿Cuál es el comportamiento esperado?

Registro de cambios y envío al repositorio central:

git status
git add all
git status
git commit -m "añadir issue template: bug"
# Se solicita firma PGP para el commit.
git push

• Se firmó el commit con PGP antes de enviarlo.
• Se usó la llave SSH al hacer el push a GitLab.

Esta secuencia sienta las bases del trabajo ágil: merge requests visibles desde el inicio, cambios atómicos, validaciones automáticas en el pipeline y plantillas estandarizadas para reportar con calidad. ¿Qué prácticas te han ayudado a mantener los merge requests pequeños y revisables? Comparte tus ideas en los comentarios.