Quality gate (puerta de calidad)

Un quality gate (puerta de calidad) es un conjunto de condiciones que un cambio debe cumplir antes de pasar a la siguiente etapa: fusionarse, desplegarse en staging o publicarse en producción. Cada condición es medible y se comprueba automáticamente; si alguna falla, el pipeline se detiene. La puerta sustituye el “a alguien le parece que está bien” por un listón explícito y acordado.

Condiciones típicas de una puerta

• Pasan todos los tests bloqueantes (unitarios, de API y un subconjunto de smoke de los end-to-end).
• La cobertura de líneas o de ramas del código nuevo no baja de un número acordado.
• No hay hallazgos nuevos críticos o altos en el análisis estático ni en el escaneo de dependencias.
• Se cumplen los umbrales de rendimiento, por ejemplo una latencia p95 inferior a 500 ms en una prueba de carga corta.
• El build es reproducible y el artefacto está firmado o versionado.

Ejemplo

Una puerta de cobertura en Jest. Si la cobertura cae por debajo de estos números, jest --coverage termina con un código distinto de cero y el job de CI falla:

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

Por sí solo, esto únicamente hace fallar un job. Se convierte en puerta cuando el job es un status check obligatorio en la protección de ramas, de modo que el botón de merge sigue deshabilitado hasta que pase. Herramientas como SonarQube agrupan varias condiciones en una única puerta con nombre y un solo resultado de aprobado/fallido.

Por qué importa

Las puertas hacen visible y coherente la definición de “listo”. Además, trasladan las discusiones al momento adecuado: el equipo debate el umbral una sola vez, al fijarlo, en lugar de hacerlo en cada release.

Errores comunes

• Poner la puerta en números que se pueden manipular. Una regla rígida del 90 % de cobertura invita a escribir tests que ejecutan código sin comprobar nada. Pon la puerta en la cobertura del código nuevo y revisa los propios tests.
• Comprobaciones flaky en la puerta. Una puerta que falla al azar acaba saltándose. Deja como bloqueantes solo las comprobaciones deterministas; ejecuta el resto como no bloqueantes, con alertas.
• Demasiadas puertas, demasiado tarde. Diez condiciones comprobadas solo antes de la release producen un montón de fallos que nadie tiene tiempo de arreglar. Coloca las comprobaciones baratas al principio, en cada pull request.
• Excepciones silenciosas. Si una puerta se puede saltar, registra quién la saltó y por qué.