Conceptos CI/CD para QA

¿Qué es CI/CD? #

CI/CD significa Continuous Integration y Continuous Delivery (o Continuous Deployment). Es un conjunto de prácticas y herramientas que automatizan cómo el software se construye, testea y libera. Para ingenieros QA, entender CI/CD ya no es opcional — es una competencia central que separa a los testers modernos de aquellos atrapados en procesos manuales.

En un flujo de trabajo tradicional, los desarrolladores escriben código por semanas y luego lo entregan a QA para testing. Los bugs encontrados semanas después de codificar son costosos de corregir. CI/CD elimina esta demora automatizando el ciclo build-test-deploy para que cada cambio de código sea validado en minutos.

Continuous Integration (CI) #

Continuous Integration es la práctica de fusionar todas las copias de trabajo de los desarrolladores en una línea principal compartida varias veces al día. Cada fusión dispara un proceso automatizado:

1. El código se descarga del repositorio
2. Las dependencias se instalan y la aplicación se compila
3. Los tests automatizados se ejecutan — tests unitarios, linting, análisis estático
4. Los resultados se reportan al equipo

El principio clave: si un test falla, el build está “roto” y arreglarlo se convierte en la prioridad máxima del equipo. Nadie hace commit de nuevo código sobre un build roto.

Por qué CI importa para QA #

• Detección temprana de bugs: Los bugs se detectan minutos después de ser introducidos, no semanas después
• Menor riesgo de integración: Fusiones pequeñas y frecuentes causan menos conflictos que las grandes e infrecuentes
• Regresión automatizada: Cada commit se verifica contra los tests existentes automáticamente
• Responsabilidad compartida: Los desarrolladores no pueden ignorar tests fallidos porque el pipeline bloquea su trabajo

Continuous Delivery (CD) #

Continuous Delivery extiende CI asegurando que el software siempre esté en un estado desplegable. Después de pasar todos los tests automatizados, el código puede liberarse a producción en cualquier momento — pero un humano debe presionar el botón.

El proceso de despliegue es automatizado y repetible. El mismo pipeline que despliega a staging puede desplegar a producción con un solo paso de aprobación.

El Pipeline de Despliegue #

Un pipeline CD típico consiste en etapas que progresivamente aumentan la confianza:

Code Commit → Build → Unit Tests → Integration Tests → Deploy a Staging → E2E Tests → Performance Tests → Security Scan → [Aprobación Manual] → Deploy a Producción

Cada etapa actúa como una quality gate. Si cualquier etapa falla, el pipeline se detiene y el equipo es notificado. El código que pasa todas las gates se considera listo para producción.

Continuous Deployment #

Continuous Deployment lleva CD un paso más allá: cada cambio que pasa el pipeline automatizado se despliega a producción automáticamente. No se necesita aprobación manual.

Esto suena arriesgado, pero funciona cuando:

• La suite de tests es completa y confiable
• El monitoreo y las alertas detectan problemas en producción instantáneamente
• Los mecanismos de rollback son rápidos y confiables
• Los feature flags controlan la exposición de nueva funcionalidad

Empresas como Netflix, Amazon y Google despliegan miles de veces al día usando continuous deployment.

Etapas del Pipeline y el Rol de QA #

Etapa 1: Build y Análisis Estático #

El servidor CI compila el código y ejecuta herramientas de análisis estático (linters, verificadores de tipos, enforzadores de estilo de código).

Participación de QA: Asegurar que las reglas de análisis estático incluyan verificaciones relacionadas con calidad. Revisar qué reglas están habilitadas y si detectan bugs comunes en tu codebase.

Presupuesto de tiempo: 1-5 minutos.

Etapa 2: Tests Unitarios #

Tests rápidos y aislados que verifican funciones y clases individuales.

Participación de QA: Revisar reportes de cobertura de tests unitarios. Identificar rutas de código sin testear y coordinar con desarrolladores para llenar los vacíos.

Presupuesto de tiempo: 2-10 minutos.

Etapa 3: Tests de Integración #

Los tests verifican que los componentes funcionan juntos — contratos API, operaciones de base de datos, comunicación entre servicios.

Participación de QA: Escribir y mantener tests de integración, especialmente tests a nivel de API. Definir qué integraciones son críticas para testear.

Presupuesto de tiempo: 5-15 minutos.

Etapa 4: Despliegue a Staging #

La aplicación se despliega a un entorno de pre-producción que refleja producción lo más fielmente posible.

Participación de QA: Verificar la salud del despliegue. Comprobar que las configuraciones, migraciones y variables de entorno sean correctas.

Presupuesto de tiempo: 2-5 minutos.

Etapa 5: Tests End-to-End #

Tests automatizados que simulan flujos reales de usuario a través del stack completo de la aplicación.

Participación de QA: Ser dueño de la suite E2E. Decidir qué journeys críticos de usuario deben pasar antes de cualquier release.

Presupuesto de tiempo: 10-30 minutos.

Etapa 6: Performance y Seguridad #

Tests de carga, tests de estrés y escaneos de seguridad aseguran que la aplicación cumpla requisitos no funcionales.

Participación de QA: Definir líneas base de performance y reglas de escaneo de seguridad. Analizar resultados y decidir si los problemas son bloqueadores.

Presupuesto de tiempo: 10-20 minutos.

Herramientas CI/CD Comunes #

Cada herramienta tiene sus fortalezas. En las próximas tres lecciones, profundizaremos en Jenkins, GitHub Actions y GitLab CI — las tres plataformas CI/CD más utilizadas.

Anti-Patrones de CI/CD #

El Pipeline “Funciona en Mi Máquina” #

Cuando el entorno CI difiere de los entornos de desarrollo y producción, los tests pasan localmente pero fallan en CI (o viceversa). Solución: usa contenedores (Docker) para asegurar entornos idénticos en todas partes.

El Pipeline Lento #

Un pipeline que toma más de una hora da feedback demasiado tarde. Los desarrolladores cambian de contexto a otras tareas y pierden el enfoque. Solución: paraleliza etapas de test, usa caché y mantén cada etapa dentro de su presupuesto de tiempo.

El Pipeline Ignorado #

Cuando el equipo habitualmente ignora fallos de tests o reintenta hasta que las cosas pasen, el pipeline se vuelve decorativo en lugar de protector. Solución: trata los builds rotos como el problema de mayor prioridad. Nunca fusiones código con tests fallidos.

El Cuello de Botella de la Gate Manual #

Si un solo ingeniero QA debe aprobar manualmente cada despliegue, se convierte en un cuello de botella que ralentiza a todo el equipo. Solución: automatiza quality gates con criterios claros de éxito/fallo. Reserva el testing manual para sesiones exploratorias, no para aprobaciones de gates.

Ejercicio: Mapea Tu Proceso Actual a CI/CD #

Piensa en un proyecto en el que trabajas (o uno hipotético si estás comenzando). Responde estas preguntas:

1. ¿Con qué frecuencia tu equipo integra código? (¿Una vez al día? ¿Una vez por sprint? ¿Al final de un feature?)
2. ¿Qué pasa cuando los tests fallan? (¿Se bloquea el build? ¿Los desarrolladores pueden fusionar de todos modos?)
3. ¿Cuánto tiempo pasa desde el commit hasta el despliegue a producción?
4. ¿Qué porcentaje de tu testing es automatizado vs. manual?

Ahora mapea tu proceso actual a niveles de madurez CI/CD:

Fundamentos de Configuración de Pipeline #

Cada herramienta CI/CD usa un archivo de configuración que define el pipeline. Aunque la sintaxis varía, los conceptos centrales son universales:

Triggers #

¿Cuándo debería ejecutarse el pipeline?

# Ejemplo: Ejecutar en cada push a main y en pull requests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

Etapas (o Jobs) #

¿Qué pasos secuenciales deberían ejecutarse?

stages:
  - build
  - test
  - deploy

Steps #

¿Qué comandos se ejecutan dentro de cada etapa?

steps:
  - name: Instalar dependencias
    run: npm ci
  - name: Ejecutar tests unitarios
    run: npm test
  - name: Ejecutar tests E2E
    run: npx playwright test

Artefactos #

¿Qué archivos deberían guardarse entre etapas?

Reportes de tests, capturas de pantalla de tests E2E fallidos, reportes de cobertura y outputs de build son artefactos comunes. Ayudan a depurar fallos después de que el pipeline completa.

Variables de Entorno y Secrets #

Valores de configuración y credenciales que el pipeline necesita:

env:
  NODE_ENV: test
  DATABASE_URL: ${{ secrets.TEST_DB_URL }}

Nunca escribas secrets directamente en archivos de configuración del pipeline. Usa la funcionalidad de gestión de secrets de tu herramienta CI/CD.

Checklist de QA para Preparación CI/CD #

Usa esta checklist para evaluar si el pipeline CI/CD de tu equipo está listo para QA:

• Cada commit dispara un build automatizado
• Tests unitarios se ejecutan en cada build con al menos 80% de cobertura
• Tests de integración verifican contratos API críticos
• Tests E2E cubren los 5-10 journeys de usuario principales
• Los resultados de tests son visibles en pull/merge requests
• Tests fallidos bloquean la fusión
• El pipeline se ejecuta en menos de 30 minutos (ruta rápida) o 1 hora (ruta completa)
• Los entornos de test se aprovisionan automáticamente
• El proceso de rollback está documentado y testeado
• Las alertas de monitoreo se disparan cuando ocurren problemas en producción post-despliegue

Conclusiones Clave #

1. CI/CD no es solo una preocupación de DevOps — los ingenieros QA deben entender e influir en cada etapa del pipeline
2. La automatización es la base — los procesos manuales no escalan en entornos CI/CD
3. La velocidad importa — los ciclos de feedback rápidos permiten a los desarrolladores corregir problemas mientras el contexto está fresco
4. Las quality gates deben ser automatizadas — el pipeline debería ser el gatekeeper, no una persona aprobando manualmente cada cambio
5. Comienza donde estás — incluso CI básico (builds automatizados + tests unitarios) es una mejora masiva sobre procesos manuales