Merge requests y control de calidad en GitLab

Contenido del curso

Introducción

Administración

Planificación

Verificación

Empaquetación

Seguridad

Distribución

Monitoreo

Conclusiones

53
Automatización en desarrollo con DevOps y GitLab
02:29 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0012:24

Merge requests y control de calidad en GitLab

Curso de DevOps con GitLab

Clase 20 de 53

Clase 20 / 53

Comentarios (37)37 comentarios

Pablo Aquino

Hace 6 años

Los merge request, es la puerta entre el código de desarrollo y producción.
En merge request es necesario saber si se corrigieron los issues, si se están introduciendo vulnerabilidades de seguridad, como es la performance de la aplicación.
Es importante que los merge request sean atómicos, y no se encuentren ligados a varios archivos, con el fin de poder realizar revisiones a profundidad.
En GitLab, se pueden realizar merge request a partir de un issue, donde nos creará un merge request y una rama referente al issue.

WIP: Work In Progress

git branch rama ramaremota nos crea una nueva rama referenciada la rama remota.
Para generar un template en GitLab debe tener la siguiente estructura .gitlab/issue_template/nombretemplate.md

Alex Arevalo

Hace 6 años

Draft merge requests Indica que un merge request aún no está lista para combinarse, quizás debido a un desarrollo continuo o subprocesos abiertos, ayuda a evitar que se acepte el merge request antes de que esté lista marcándola como Draft. Esto desactivará el botón "Merge", evitando que se fusione, y permanecerá desactivado hasta que se elimine la marca Draft.

https://docs.gitlab.com/ee/user/project/merge_requests/work_in_progress_merge_requests.html

Jonatan Lazo

Hace 7 años

No se encuentra funcionando este video!

Kevin Morales

Hace 7 años

Ya se encuentra disponible :)

Domingo Ramírez

Hace 6 años

Es lo mismo que un pull request cierto?

Gonzalo Amador Hernández

Hace 6 años

asi es PR (pull request) en GitHub es lo mismo que MR (merge request) en GitLab

Victor Andres Pedraza León

Hace 7 años

Ya funcionó muchachos!

Saludos.

Gonzalo Amador Hernández

Hace 6 años

Recomiendo esta extension para vscode para manejar git de forma grafica

Diego Forero

Team Platzi

Hace 7 años

Ya estamos revisando y sera solucionado lo más pronto posible. Gracias a todos por el reporte.

José Luis García Peceros

Hace 7 años

No puedo ver el vídeo :(

Marcelo Javier Pedernera

Hace 7 años

Acá me perdí un poco con las líneas de código...

Daniel Alfredo García Serna

Hace 6 meses

📚 Nombre de la clase

Merge Requests y control de calidad en GitLab

🎯 Idea principal

Los Merge Requests (MR) en GitLab permiten revisar, discutir y validar cambios antes de integrarlos al código principal. Son una pieza clave para asegurar calidad, colaboración y control en el desarrollo. Funcionan como un punto de validación donde el código es analizado antes de ser aceptado. El objetivo es evitar errores en producción mediante revisión estructurada.

⚡ Síntesis en 10 segundos

MR = revisión antes de integrar código
Aseguran calidad del software
Fomentan colaboración
Detectan errores temprano
Control antes del merge

🔑 Puntos clave

Merge Request: solicitud para integrar cambios a una rama principal
Permite revisión de código por otros miembros del equipo
Incluye comentarios, sugerencias y discusión
Puede integrarse con pipelines CI/CD para validación automática
Evita subir código sin revisión
Mejora calidad y consistencia del código
Facilita colaboración y aprendizaje entre desarrolladores

🧠 Conceptos importantes

Merge Request (MR): proceso de integración de cambios revisados
Code Review: revisión del código por otros desarrolladores
Rama (branch): versión paralela del código
Validación: proceso de comprobar que el código funciona correctamente
Integración: unión de cambios al código principal

🧩 Modelo mental de la clase

Cambio → Merge Request → Revisión → Validación → Aprobación → Integración

Idea clave: Ningún cambio debería entrar sin ser revisado.

🚀 Acciones inmediatas

Crear un Merge Request para tus cambios
Solicitar revisión de otro desarrollador
Revisar código antes de aprobar
Integrar CI/CD para validaciones automáticas
No hacer merge sin revisión previa

💼 Aplicación profesional

En empresas: asegurar calidad del código en equipos grandes
En equipos: fomentar colaboración y aprendizaje
En proyectos: evitar errores en producción
En productos digitales: mantener estabilidad del sistema

Impacto real: menos bugs, mejor código y procesos más profesionales.

🔥 Hacks para la comunidad

No revises solo por cumplir → revisa con criterio
Automatiza validaciones con CI/CD
Mantén MR pequeños y enfocados
Usa comentarios para enseñar y aprender
MR grande = revisión difícil = más errores

📝 Reflexión estratégica

La calidad no se construye al final, se asegura en el proceso. Los Merge Requests son un filtro que protege el producto.

Los equipos que revisan bien su código construyen software más confiable.

Victor bustos sazo

Hace 6 años

Trato de instalar nodejs en un ubunto 18.04, - y tengo el siguiente error, alguien sabe como podria corregir o donde buscar ?

npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142 npm WARN deprecated chokidar@2.1.8: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies. npm WARN deprecated fsevents@1.2.13: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2. npm WARN deprecated urix@0.1.0: Please see https://github.com/lydell/urix#deprecated npm WARN deprecated resolve-url@0.2.1: https://github.com/lydell/resolve-url#deprecated npm ERR! Unexpected end of JSON input while parsing near '...hREV4GuAha/kbDcqqVbkb'

npm ERR! A complete log of this run can be found in: npm ERR! /home/victor/.npm/_logs/2020-05-08T05_54_31_748Z-debug.log

gracias

Walter Lensinas

Hace 5 años

Hola Victor, se que paso un tiempo de esto, pero te recomiendo usar node version manager (nvm) para poder instalar distintas versiones de nodejs en tu maquina.

https://github.com/nvm-sh/nvm

Paul Sanchez Pardo

Hace 6 años

Culés son los short codes de git?

Juan Jose Vega

Hace 6 años

Hay muchos El curso de Git te enseña unos Y en los comentarios hay guías muy top que puedes seguir

Joel Guillén

Hace 7 años

¿Es ideal trabajar con 2 ramas (master - development), para no pushear directamente a máster ? O solo es opcional ?

Fernando Salas

Hace 7 años

Joel es ideal y muy recomendable trabajar con multiples ramas, puedes tener una rama (master) con los ultimos features de tu projecto y a la vez tener diferentes ramas en las que trabajas en una funcionalidad en especifico (development, develop2, bugfix11, etc...).

Tener multiples ramas te ayudara a trabajar mejor en quipo.

Fernando Salas

Hace 7 años

Tener multiples ramas te ayudara a trabajar mejor en quipo.

Arturo Escamilla García

Hace 7 años

¿Por cada proyecto creado corresponde una claves ssh?

José de Jesús Uscanga Molina

Hace 7 años

No , tu SSH es global

Pablo Aquino

Hace 6 años

No necesariamente, pero si debes de ligar tu proyecto a tu llave ssh pública.

Alex Naupay

Hace 2 años


git fetch --all

git switch \<branch>

Alfredo Olmedo

Hace 2 años

Flujo de trabajo en un Merge request:

1 Crear una rama
2 Realizar Cambios
3 Empujar la rama al reposiutorio remoto
4 Crear un Merge Request
5 Revision y Aprobacion
6 Merge
7 Eliminar la rama

Este flujo de trabajo ayuda a asegurar que el codigo sea revisado y aprobado antes de ser integrado, mejorando la calidad y estabilidad del proyecto

Carlos Sulbaran

Hace 4 años

Hola, a mi no me salia cuando hacia git pull la nueva rama y tengo algo de experiencia en git y cuando hacia git branch tampoco me salia, lo que hice fue git branch -r y me mostro la rama que se acababa de crear y pude hacer un git switch NombreDeLaRama* para usar esa rama

Espero le sirva a alguien

victor rodriguez

Hace 4 años

vamos de maravilla este profesor es genial. GRACIAS

Jonathan Grimaldo Rodriguez

Hace 5 años

Excelentes buenas practicas las que voy aprendiendo en este curso, excelente!!

Wilmer Ariel Moina Rivera

Hace 7 años

Tal vez te sirva.

https://git-scm.com/docs/git-branch

Recursos

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.

Introducción

DevOps con GitLab para automatizar entregas de software

Qué es DevOps y cómo integra desarrollo con operaciones

DevOps como ciclo iterativo continuo: etapas y beneficios clave

GitLab como plataforma integral para el ciclo de vida DevOps

Diferencias clave entre GitLab y GitHub para desarrolladores

Administración

Configuración de autenticación segura en GitLab

Grupos y subgrupos de GitLab para organizar proyectos y permisos

Gestión de permisos y colaboradores en GitLab

Rastros de auditoría en GitLab para administración segura

Creación y configuración de proyectos en GitLab

Planificación

Diferencias entre Agile y Waterfall en desarrollo de software

Creación y gestión de issues en GitLab para colaboración eficaz

Etiquetas para organizar issues en GitLab

Planificación en Gitlab-Pesos

Creación y gestión de milestones en GitLab para sprints y releases

Boards en GitLab para visualizar flujos de trabajo con issues

Service Desk de GitLab para soporte por correo electrónico

Planificación en Gitlab-Quick actions

Verificación

Inicialización de Angular con GitLab y test-driven development

Merge requests y control de calidad en GitLab

Flujo completo de merge requests en GitLab

Automatización de flujos de trabajo con GitLab CI

GitLab CI: configuración, stages y variables para automatización

Configuración de GitLab CI para proyectos Angular

Validación de archivos GitLab CI con linter antes del pipeline

gitlab-ci.yml

Configuración de GitLab Pages para hosting estático con CI

Configuración de GitLab Pages para deploy automático de Angular

Desarrollo ágil y sus doce principios fundamentales

GitLab AutoDevOps: pipelines automatizados con seguridad y calidad

Configuración de GitLab Auto DevOps con Kubernetes en Google Cloud

Configuración de Auto DevOps en GitLab con Kubernetes

Empaquetación

Integración de GitLab Container Registry con Auto DevOps

Introducción a contenedores

Seguridad

DevSecOps: integración de seguridad en el ciclo de desarrollo

Autenticación de commits con llaves PGP en GitLab

Pruebas estáticas de seguridad en GitLab para detectar vulnerabilidades

Análisis de contenedores con GitLab y Clair para detectar vulnerabilidades

Análisis de vulnerabilidades en dependencias de NPM, PIP y Composer

Pruebas dinámicas de seguridad con DAST en GitLab

GitLab Security Dashboard: hub centralizado de vulnerabilidades

Distribución

Continuous Deployment seguro con GitLab y control de riesgos

Configuración de ambientes en GitLab para desarrollo industrial

Review apps: ambientes efímeros por branch para feedback rápido

Estrategias de Distribución

Feature Flags

Rollback en GitLab para revertir errores en producción

Monitoreo

Importancia del monitoreo en DevOps y despliegue continuo

Métricas de desempeño en GitLab con Prometheus

Métricas de salud en GitLab para prevenir fallas de infraestructura

Métricas de equipo en GitLab para optimizar workflows de DevOps

Integración de GitLab con Sentry para rastrear errores en producción

Conclusiones

Automatización en desarrollo con DevOps y GitLab

Merge requests y control de calidad en GitLab