English

Ordena las etapas de CI de la más barata a la más costosa

Tu CI pierde diez minutos atrapando un typo que el lint podría marcar en treinta segundos. La solución no es una máquina más rápida — es el orden. Ejecuta primero los chequeos más baratos y con más probabilidad de fallar, y un commit malo muere en segundos en vez de después de toda la suite de tests.

Por qué el orden le gana a la potencia

Cuanto más tarde se detecta un defecto, más cuesta arreglarlo. Las cifras del IBM Systems Sciences Institute, muy citadas, ubican un defecto encontrado en diseño en 1x, en implementación ~6.5x, en testing ~15x, y después del release 60–100x. La misma lógica aplica dentro de una sola corrida de CI a escala de minutos: un typo atrapado por el lint te cuesta 30 segundos; ese mismo typo detectado recién cuando el job de tests revienta te cuesta toda la corrida de diez minutos más el cambio de contexto.

Así que el objetivo de un pipeline no es solo "ejecutar cada chequeo". Es exponer el fallo más barato lo antes posible. Cada segundo que un commit condenado pasa en tus etapas lentas es puro desperdicio.

La regla de ordenamiento

Ordena las etapas por dos ejes y ejecútalas en este orden: lo barato y frágil primero, lo costoso y sólido al final.

Léelo de arriba hacia abajo: el lint falla ante un typo antes de que el type-checker siquiera arranque; el type-checker rechaza una firma mala antes de que corra un solo test; los tests atrapan la lógica antes de que gastes un build. Cada compuerta es más barata y con más chance de dispararse que la de abajo, así que el commit promedio que falla sale temprano.

Haz que CI realmente se detenga temprano

El orden solo rinde si una etapa fallida bloquea la siguiente. En GitHub Actions, encadena jobs con needs para que un job costoso nunca arranque hasta que su predecesor barato esté en verde:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [ { uses: actions/checkout@v4 }, { run: make lint } ]
  typecheck:
    needs: lint
    runs-on: ubuntu-latest
    steps: [ { uses: actions/checkout@v4 }, { run: make typecheck } ]
  test:
    needs: typecheck
    runs-on: ubuntu-latest
    steps: [ { uses: actions/checkout@v4 }, { run: make test } ]

Si un job del que depende (needs) un job posterior falla o se omite, GitHub Actions omite el job dependiente por defecto — así que test nunca corre cuando lint está en rojo.

Movimientos avanzados

• Saca la compuerta más barata de CI por completo. Ejecuta formato + lint como un hook de pre-commit para que el typo nunca llegue al runner. Los hooks corren en segundos sobre los archivos modificados, en cada commit — la detección más temprana posible.
• Cancela corridas reemplazadas. Agrega un grupo concurrency con cancel-in-progress: true para que un nuevo push mate la corrida en vuelo de la misma rama en lugar de pagar por una obsoleta.
• Paraleliza lo independiente, controla lo dependiente. El lint y el type-check a menudo no dependen entre sí — córrelos en paralelo, y luego haz que test los needs a ambos. Mantienes el fail-fast sin serializar chequeos que podrían superponerse.
• Divide la suite lenta. Si los tests dominan, corre primero un subconjunto rápido de smoke y controla la matriz completa detrás de él. El mismo principio, un nivel más profundo.

El beneficio

Ahora un typo falla rápido y fuerte en segundos, no después de una corrida de diez minutos. Tus etapas lentas y costosas solo corren sobre commits que ya pasaron las baratas — así que tus minutos de runner, y tu atención, van a los cambios que de verdad los merecen.

Recursos

• Cost of Defects in Software Testing: 2026 Data & Multipliers — las cifras de escalamiento de costo de IBM/NIST
• GitHub Actions: workflow syntax — jobs.<job_id>.needs — encadenar jobs para que las compuertas baratas bloqueen las costosas
• GitHub Actions: using concurrency (cancel-in-progress) — cancelar corridas reemplazadas
• pre-commit — ejecutar lint/format antes de que el commit llegue a CI