Quality Gates en el pipeline de CI/CD: montaje en cuatro etapas

Una cadena de controles eficaz se reparte en cuatro etapas: segundos en el commit, minutos en la pull request, a fondo antes del merge, con dureza antes del despliegue. El orden obedece a un único principio: cuanto antes se detecta un error, más barato resulta, así que cada control debe colocarse lo más adelante que su duración permita.

¿Cómo integro Quality Gates en un pipeline de CI/CD?

En cuatro etapas, con un presupuesto de tiempo claro para cada una. El presupuesto importa más que la exhaustividad: un pipeline que tarda cuarenta minutos acaba siendo esquivado.

¿Qué control corresponde a cada etapa?

La asignación depende de la duración, no de la importancia. Un control importante que tarda diez minutos tampoco pertenece a la etapa 1: de lo contrario se desactivará la etapa 1 y todos los controles que contiene se perderán con ella.

• La etapa 1 debe pasar inadvertida. Lo que aquí dure más de unos segundos se percibe como una molestia. Revise solo los archivos modificados, no el proyecto entero.
• La etapa 2 es la verdadera puerta de calidad. Aquí se decide si un cambio merece siquiera ser discutido. Todo lo que puede decidirse de forma automática pertenece aquí, de modo que en la revisión solo queden las preguntas que requieren a una persona.
• La etapa 3 puede ser costosa porque se ejecuta pocas veces. Pruebas de integración contra dependencias reales, pruebas de las rutas principales en el navegador.
• La etapa 4 no es una revisión de código. Aquí lo que importa es el proceso en sí; más sobre ello a continuación.

¿Cómo mantengo rápido el pipeline?

Con cuatro medidas que, juntas, marcan la diferencia entre veinte minutos y tres.

• Revisar solo lo que ha cambiado. El análisis estático y el linter necesitan el diff, no el repositorio.
• Almacenar en caché los estados intermedios. Las dependencias y los artefactos de build pertenecen a la caché, no a cada ejecución.
• En paralelo en lugar de en serie. Las pruebas, el análisis y el build no dependen entre sí en cuanto al orden.
• Abortar pronto. Si el linter falla en el segundo tres, la batería de pruebas de doce minutos ya no tiene que ejecutarse.

¿Por qué es el gate de despliegue el más importante?

Porque es la única etapa en la que un error no solo es caro, sino también visible de inmediato. Un code smell que se cuela le cuesta tiempo dentro de seis meses. Una migración irreversible o un archivo incluido que nunca debió llegar a un servidor le cuesta esta misma noche.

Por eso un gate de despliegue revisa cosas distintas que las etapas anteriores:

• ¿Qué se transfiere realmente? Cada archivo del alcance de transferencia debe clasificarse: pertenece al servidor, pertenece solo al entorno local, no debe llegar nunca a un servidor. Los archivos de configuración, las credenciales y las herramientas de desarrollo entran en el tercer grupo.
• ¿Hay un cambio de esquema y es reversible? Una migración sin contrapartida es una calle de sentido único. Antes: acreditar la copia de seguridad.
• ¿Existe una vía de reversión y se ha probado? Una vía de reversión que nunca se ha ensayado es una suposición.
• ¿Se ejecuta después algo que compruebe el éxito? Una prueba de humo tras el despliegue marca la diferencia entre «entregado» y «funciona».

Ninguna de estas cuatro preguntas se resuelve con más pruebas: se refieren al proceso, no al código. Por eso la etapa 4 necesita su propia barrera, véase Qué es un Quality Gate.

¿Cómo introduzco gates sin bloquear la operación en curso?

Primero de forma observadora, después bloqueante, y siempre solo para el código nuevo.

• Semanas 1 y 2: solo informar. Todos los controles se ejecutan, ninguno aborta. Verá con qué frecuencia saltaría cada criterio.
• Semana 3: activar los casos claros. Las pruebas fallidas y los secretos en el código abortan el proceso. Nadie discute estos dos.
• Después: fijar una línea base y endurecer lo nuevo. Lo existente se congela y para las líneas modificadas rige todo el rigor. El procedimiento está en el artículo sobre el análisis estático de código.

Preguntas frecuentes sobre los Quality Gates en el pipeline

¿Cuál es la diferencia entre CI y CD?

La integración continua (Continuous Integration) designa la fusión frecuente de los cambios y su verificación automática. La entrega continua o el despliegue continuo (Continuous Delivery o Deployment) designa la entrega automatizada de la versión verificada. Los gates de las etapas 1 a 3 pertenecen a la CI, la etapa 4 a la CD.

¿Debe abortar el pipeline ante cada hallazgo del análisis?

No, solo por encima de una gravedad establecida y solo ante hallazgos nuevos. Quien aborta ante cada observación de estilo genera atajos en lugar de calidad.

¿Cómo trato las pruebas poco fiables?

Como un problema propio, no como ruido. Una prueba que a veces falla sin motivo cuesta más de lo que aporta: acostumbra al equipo a repetir las ejecuciones en rojo en lugar de leerlas. O se repara o se elimina.

¿Necesito un hook de Git para la etapa 1?

Un hook local es la vía habitual, pero se puede esquivar y reside en el equipo de cada persona. No confíe únicamente en él: lo que se revisa en la etapa 1 debería ejecutarse de nuevo en la etapa 2.

¿Qué archivo de su último despliegue no tenía en realidad nada que hacer en el servidor? Si no puede responder de inmediato, ahí está justo la laguna. Code Guardian clasifica cada archivo del alcance de transferencia y trata cada migración como irreversible hasta que se demuestre lo contrario.

Fuentes

• OWASP Top 10:2025, categoría A03 «Software Supply Chain Failures» (justificación de la revisión de dependencias en la etapa 2).
• ISO/IEC 25010:2023 (características de calidad como marco de referencia para los criterios de los gates).

Fecha: 27 de julio de 2026. Valoración técnica de carácter general; los presupuestos de tiempo concretos dependen del tamaño del proyecto y de la infraestructura.