---
title: "Smoke, carga y stress en CI: pipeline mínimo que igual atrapa regresiones"
description: "Smoke, carga y stress en CI: pipeline k6 mínimo con umbrales—tipos de test k6.io más gates rápidos en merge vs suites programadas."
publishDate: "2026-07-27"
draft: false
keyword: "pruebas rendimiento en ci"
intent: "MOFU"
cta: "Usa Performate para convertir este playbook en escenarios k6 ejecutables, umbrales y reportes compartibles sin perder días en código de integración."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "ci"]
translationOf: smoke-load-stress-ci-pipeline
---

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](https://k6.io/docs/test-types/)). 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](/es/blog/flujo-escritorio-postman-k6-reportes)) debe ocurrir antes de que CI cargue el script.

## Capas de gates: frecuencia vs riesgo

| Capa | Duración | ¿Bloquea merge? | Trigger típico |
|:---|:---|:---|:---|
| Smoke | 1–3 min | Sí | Cada PR / merge a main |
| Carga | 10–20 min | Nocturno / rama release | Programado + pre-release |
| Stress | 30+ min | Semanal / manual | Cambio infra, ensayo lanzamiento |

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.

```javascript
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](/es/blog/revision-salud-escenarios-k6-trimestral) compara evidencia.
- **Smoke usa secretos staging** vía almacén de secretos CI ([k6 secretos](/es/blog/k6-secretos-entornos-prueba)) — 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.

```bash
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

| Evento | Perfil | ¿Bloquea deploy? |
|:---|:---|:---|
| PR abierto | smoke | Sí, si en camino crítico |
| Main nocturno | load | Alerta, block opcional |
| Semana pre-lanzamiento | stress (manual) | Advisory salvo comité SLO |
| Rama hotfix | smoke mínimo | Sí |
| Resize infra | load + stress opcional | Sí en gate staging |

**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](/es/blog/k6-secretos-entornos-prueba)) — 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](/es/blog/revision-salud-escenarios-k6-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](https://performate.app) | [Pruebas de carga en CI/CD](/es/blog/pruebas-de-carga-en-ci-cd) | [Book a demo](/demo)