Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo.

Siguiendo con esta seria de blogs inspirados en el libro “How Google Tests Software”, déjame hacerte una pregunta sencilla. ¿Cuánto tarda tu pipeline en ejecutarse? 5 minutos… 15 minutos… ¿30 minutos o más?

Ahora otra pregunta un poco más incómoda: ¿Cuántas veces alguien en tu equipo dice algo como esto?

“Mejor no corras todo el pipeline porque tarda demasiado.”

Si esto pasa en tu equipo, es muy probable hayan espacios de mejora en cómo están distribuidas las pruebas dentro del pipeline. Pero antes de hablar de eso, primero vamos a aclarar algo importante.

Porque muchas personas que están comenzando en QA o desarrollo todavía no tienen claro qué es exactamente un pipeline.

¿Qué es un pipeline?

Un pipeline de CI/CD es básicamente una serie de pasos automatizados que ocurren cada vez que alguien intenta integrar cambios en el código del proyecto.

En otras palabras:

Es el proceso que revisa tu código antes de que llegue al producto.

El pipeline ayuda a responder preguntas como:

• ¿El código compila?
• ¿Las pruebas siguen funcionando?
• ¿El cambio rompe algo existente?
• ¿El sistema puede desplegarse correctamente?

Si algo falla en el pipeline, el código no debería avanzar o ser incluido en le repositorio principal.

Y esto es exactamente lo que lo vuelve tan importante para todo el equipo. El pipeline se convierte en una especie de guardian del proyecto, como un filtro de calidad.

¿Qué ocurre normalmente dentro de un pipeline?

Cada empresa puede diseñar su pipeline de forma diferente, por ello nos siempre cada paso se cumple, pero la mayoría sigue una estructura parecida.

Vamos a ver algunos de estos pasos:

1. Compilación del proyecto

Lo primero que ocurre es verificar que el código compile correctamente. Si el proyecto no compila, el pipeline se detiene inmediatamente. Aquí el objetivo es detectar errores simples lo más rápido posible.

2. Análisis de calidad del código

Muchas empresas agregan herramientas que revisan automáticamente la calidad del código.

Algunas de esta herramientas son:

• SonarQube
• Code Climate
• Snyk
• ESLint
• Checkstyle

Estas herramientas ayudan a detectar problemas como:

• vulnerabilidades
• duplicación de código
• malas prácticas
• problemas de seguridad

Y todo esto antes de que el código llegue a producción.

3. Ejecución de pruebas automáticas

Aquí es donde ocurre una de las partes más importantes del pipeline. Las pruebas automáticas ayudan a responder una pregunta crítica:

”¿Este cambio rompió algo?”

Dependiendo del proyecto, aquí pueden ejecutarse distintos tipos de pruebas:

• pruebas unitarias
• pruebas de integración
• pruebas de API
• pruebas end-to-end

Y aunque no lo creas, muchas empresas no tiene claridad sobre como distribuir las pruebas en este punto.

El error que hace que los pipelines sean lentos

En muchos equipos ocurre algo así: El pipeline ejecuta primero pruebas lentas -> End-to-end -> UI tests. Estas son pruebas complejas que pueden influir en que el pipeline tarde 20 o 30 minutos en darte feedback. ¿El problema? Generalmente los desarrolladores hacen cambios incluso luego de las discusiones de los desk checks, o hot fix que requieren ser incluidos con premura y un pipeline que tarda tanto en ejecutarse puede acabar por ser un problema para el desarrollo, e incluso para el negocio.

Entonces, ¿Cómo distribuir las pruebas dentro del pipeline para evitar estos problemas?

Un pipeline eficiente no ejecuta todas las pruebas al mismo tiempo, sino se organizan por velocidad y alcance. Comenzando desde las Small, siguiendo a las Medium y finalizando con las Larges.

Si te interesa saber de este enfoque, puedes leer mi blog de la semana pasada acá. Porque un buen pipeline no solo ejecuta pruebas. Le da información al desarrollador y es un apoyo para todo el equipo. Esta información es rápida y confiable si el pipeline está bien diseñado. De esta forma él puede saber:

• Si rompió algo
• Se evita que el equipo integre código defectuoso
• El proyecto mantiene builds estables

Y de nuevo algo muy importante, el pipeline no debería permitir que código no validado llegue al repositorio principal. Siento este uno de sus mayores beneficios.

Herramientas que ayudan a visualizar pipelines

Hoy existen muchas herramientas que permiten visualizar pipelines y entender qué está ocurriendo en cada etapa.

Algunas de las más utilizadas son:

• GitHub Actions
• GitLab CI/CD
• Azure DevOps Pipelines
• Jenkins
• CircleCI
• Bitbucket Pipelines
• Travis CI

Muchas de estas herramientas también permiten generar reportes sobre:

• resultados de pruebas
• cobertura de código
• tiempos de ejecución
• historial de builds

Esto ayuda a los equipos a entender dónde están los cuellos de botella.

Para concluir:

Cuando un pipeline tarda demasiado, muchas personas dicen: “El pipeline está mal.” Pero como cualquier herramienta de automatización, el pipeline solo está haciendo lo que le pedimos. Por ello siempre ten como objetivo participar en el análisis y distribuición de estas pruebas, pues te ayudaran a repartir los puntos de chequeo dentro de tu estrategia de calidad.

---

📥 Recurso descargable

Plantilla: Auditoría rápida de tu pipeline

Si quieres evaluar rápidamente si tu pipeline está bien diseñado, puedes usar esta pequeña guía.

Paso 1: Identifica las etapas actuales

Escribe las etapas de tu pipeline.

Por ejemplo:

• build
• análisis de código
• pruebas
• deploy

Paso 2: Clasifica las pruebas

Para cada tipo de prueba responde:

¿Es rápida o lenta?

¿Depende de infraestructura externa?

¿Puede ejecutarse en paralelo?

Clasifícalas como:

• Small
• Medium
• Large

Paso 3: Revisa el orden

Pregúntate:

¿Las pruebas más rápidas se ejecutan primero?

¿El pipeline se detiene temprano cuando algo falla?

¿El feedback llega antes de 10 minutos?

Paso 4: Busca oportunidades de mejora

Si tu pipeline tarda demasiado:

• mueve pruebas lentas al final
• aumenta small tests
• ejecuta pruebas en paralelo

Pequeños cambios aquí pueden ahorrar mucho tiempo al equipo.

Espero que este contenido te sea de aydua y nos vemos el próximo lunes.