Smoke, carga y stress en CI: pipeline mínimo que igual atrapa regresiones

Un stress de tres horas en cada PR entrena a desactivar el pipeline. Perf mínima en CI significa: smoke rápido en merge, carga programada, stress manual opcional — mismo repo k6, options vía env (tipos de test k6). Los gates deben ser lo bastante rápidos para permanecer habilitados y lo bastante significativos para detectar regresiones que unit tests omiten.

Esta guía estratifica smoke, carga y stress por frecuencia, ofrece un script con switch TEST_PROFILE, y documenta qué pertenece a gates de merge vs jobs nocturnos vs rituales pre-lanzamiento. El afinado en escritorio (flujo Postman → k6) debe ocurrir antes de que CI cargue el script.

Capas de gates: frecuencia vs riesgo

Smoke demuestra wiring, auth y regresión catastrófica de latencia a bajo RPS. Carga valida tráfico con forma SLO. Stress mapea puntos de quiebre — nunca diario en staging compartido sin aprobación.

Por qué un repo vence a tres

Scripts duplicados derivan en dos sprints. Un export con variable env de perfil mantiene umbrales y definiciones de request alineados — Performate en escritorio valida el mismo archivo que corre CI.

k6: un script, switch TEST_PROFILE

Ejemplo ilustrativo — no es una prueba lista para producción. CI establece TEST_PROFILE=smoke en PR; cron nocturno establece load.

Qué demuestra este ejemplo:

• Mapa profiles único — smoke/load/stress difieren por rate, duration, thresholds.
• Tags profile en métricas para filtrar corridas nocturnas vs PR en Grafana.
• Think time escala con perfil — smoke permanece rápido; carga más realista.
• Falla build por umbrales, no solo checks — k6 sale non-zero en breach de umbral.

import http from 'k6/http';
import { check, sleep } from 'k6';

const profile = __ENV.TEST_PROFILE || 'smoke';

const profiles = {
  smoke: {
    rate: 2,
    duration: '1m',
    thresholds: {
      http_req_failed: ['rate<0.01'],
      'http_req_duration{profile:smoke}': ['p(95)<800'],
    },
  },
  load: {
    rate: 25,
    duration: '10m',
    thresholds: {
      'http_req_duration{profile:load}': ['p(95)<600', 'p(99)<900'],
      http_req_failed: ['rate<0.01'],
    },
  },
  stress: {
    rate: 60,
    duration: '15m',
    thresholds: {
      http_req_failed: ['rate<0.05'],
    },
  },
};

const p = profiles[profile] || profiles.smoke;

export const options = {
  scenarios: {
    main: {
      executor: 'constant-arrival-rate',
      rate: p.rate,
      timeUnit: '1s',
      duration: p.duration,
      preAllocatedVUs: 20,
      maxVUs: 100,
      tags: { profile },
    },
  },
  thresholds: p.thresholds,
};

export default function () {
  const res = http.get(`${__ENV.API_BASE}/api/core`, { tags: { route: 'core', profile } });
  check(res, { ok: (r) => r.status < 500 });
  sleep(profile === 'smoke' ? 0.1 : 0.4);
}

Patrones que funcionan

• Afina perfil load en escritorio hasta umbrales estables tres corridas — luego promueve a CI nocturno.
• Archiva resumen JSON por release con tag profile — revisión trimestral compara evidencia.
• Smoke usa secretos staging vía almacén de secretos CI (k6 secretos) — nunca inline en repo.
• Workflow stress manual con enlace a runbook — on-call aprueba ventana.

Anti-patrones a evitar

• Stress en cada push — pipeline deshabilitado en un mes.
• Smoke sin umbrales — pasa mientras p95 se duplicó.
• Scripts distintos CI vs local — vuelve "funciona en mi laptop".
• Correr carga contra producción desde CI sin control de cambios.

Pro tip (comando de ejemplo): switch de perfil local refleja CI.

k6 run ci-profiles.js --env TEST_PROFILE=smoke --env API_BASE=https://staging.example.com

Qué demuestra este comando: desarrolladores reproducen fallo CI en un comando antes de push de ajustes de umbral — reduce ruido en cola de merge.

Marco de decisión: qué perfil cuándo

Mantén smoke bajo tres minutos — incluye checkout, instalar k6, correr, subir artefacto si es posible.

Programa carga cuando staging está quieto — no concurrente con regresión QA completa sin coordinación.

Observabilidad y checklist CI

• Smoke usa secretos staging (k6 secretos) — rotados independientemente del repo.
• Falla build por umbrales, no solo checks — configura CI para respetar exit code k6.
• Archiva resumen JSON para revisión trimestral.
• Documenta valores TEST_PROFILE en README — on-call reproduce fallo nocturno.
• Enlaza smoke CI al mismo commit que export de escritorio validó.
• Alerta miss de umbral perfil load separado de smoke — playbooks de respuesta distintos.

Cómo Performate simplifica perf mínima en CI

Abajo hay un ejemplo de flujo concreto para promover script afinado en escritorio a CI estratificado — adapta rates a tu doc SLO.

Ejemplo: afinado escritorio → gate smoke → carga nocturna

1. Afina perfil load en escritorio hasta p95 estable — 10m a RPS de negocio. Problema resuelto: CI no se convierte en tu debugger.
2. Exporta script con switch TEST_PROFILE intacto. Problema resuelto: un archivo, tres gates — sin deriva.
3. Conecta smoke en CI en PR — TEST_PROFILE=smoke, 1–3 min. Problema resuelto: merge bloqueado por regresión real, no solo gap de unit test.
4. Programa load nocturno en main — mismo script, env distinto. Problema resuelto: señal con forma SLO sin impuesto de latencia en PR.
5. Documenta stress como workflow manual con plantilla Performate guardada. Problema resuelto: ensayo de lanzamiento existe sin costo diario.
6. Compara reportes release a release en vista comparación. Problema resuelto: tendencias visibles para release managers, no solo ingeniería.

Ese flujo mapea directamente al cta de este post: convertir playbook en escenarios ejecutables sin sprints de código de integración.

Cierre

CI gana con smoke en cada merge y carga en calendario — no stress en cada push. Exporta un script con perfiles desde escritorio, habilita gate smoke esta semana y programa carga antes del próximo release train.

Mergea el job smoke antes de añadir carga — equipos que habilitan ambos a la vez suelen deshabilitar ambos cuando las colas de staging se saturan.

Try Performate free | Pruebas de carga en CI/CD | Book a demo