Integración de Pruebas de CI/CD: Guía Práctica de Pipeline

El cambio de un servicio de pago puede pasar miles de pruebas unitarias y aún así romper la producción porque el sistema de facturación API interpreta una clave de idempotencia de manera diferente a como lo espera el servicio. La falla puede permanecer sin detectar hasta que un trabajo de integración nocturno alcance la interfaz, mucho después de que el commit haya pasado por la parte rápida del pipeline.

Es ese el problema operativo con Pruebas de integración de CI/CD. Las pruebas unitarias demuestran que la lógica aislada se comporta correctamente. Las pruebas de integración proporcionan evidencia de que los componentes, servicios, esquemas, colas y dependencias externas siguen de acuerdo. En una pila de entrega moderna, esa evidencia debería influir en las decisiones de triaje, no convertirse en una pared lenta de comprobaciones que los desarrolladores aprenden a ignorar.

La integración de CI/CD se ha convertido en un modelo de entrega de software principal. A Informe de pruebas de DevOps de 2024 de mabl dice que casi del 90% de las organizaciones globales priorizan las transformaciones de DevOps, mientras que apenas 50% de los probadores están involucrados en definir y mantener los procesos de CI/CD y solo 10% de las organizaciones informan que no despliegan CI/CD en absoluto. La consecuencia práctica es clara: la verificación de integración ahora tiene que operar a escala de entrega.

Contenido de la Tabla

• ¿Por qué las pruebas de integración son el punto de control de CI/CD?
  • Construye el punto de control deliberadamente
• ¿Dónde se encuentran las pruebas de integración entre las pruebas unitarias y las pruebas de fin a fin?
  • Tres patrones útiles de integración
• Administrar entornos y datos para pruebas fieles
  • Una secuencia de trabajo reproducible
  • Usar virtualización con intención
• Ejemplos de pipeline para GitHub Actions, GitLab CI y Jenkins
  • GitHub Actions
  • GitLab CI
  • Jenkins
• Tácticas de confiabilidad para pruebas de integración inestables
  • Medir antes de cambiar la política
  • Eliminar las causas habituales
• Gobernanza de políticas y reglas de promoción de despliegue
  • Usar barreras específicas de etapa
  • Hacer visibles los saltos
• Lista de verificación de adopción y observabilidad a largo plazo
  • Fase uno, hacer confiable la señal existente
  • Fase dos, aumentar la fidelidad del entorno
  • Fase tres, conectar observabilidad a la triage

¿Por qué la pruebas de integración es el punto de control de CI/CD?

Las pruebas de integración es donde el riesgo de liberación se vuelve concreto. Un test de unidad puede confirmar que un manipulador de pago formatea correctamente una clave de idempotencia, pero solo una prueba de integración puede probar que el manipulador, el cliente HTTP, la facturación API, el capa de persistencia y el comportamiento de retry están de acuerdo cuando operan juntos.

Por eso, la etapa de integración es el punto de control natural entre la integración continua y la entrega continua. Un commit no debería considerarse desplegable solo porque su suite de unidades es verde. Debe ganar promoción produciendo evidencia confiable de que las interfaces que cambia siguen funcionando en una disposición similar a la producción.

The distinction matters because frequent integration without automated verification only moves defects faster. A systematic review of CI/CD improvement approaches identified recurring priorities that include reducing build and test time, improving visibility into results, supporting continuous testing, detecting faults, and improving deployment reliability. Another review in the same research record defines continuous integration around frequent code integration verified by an automated build that includes tests, so defects can be detected quickly.

Construya el punto de control deliberadamente

Comience clasificando las pruebas de integración según la decisión que apoyan:

• Pruebas bloqueantes protegen contratos críticos y se ejecutan de manera sincrónica antes de la fusión o promoción.
• Pruebas cuarentenadas quedan visibles y continúan produciendo evidencia, pero no bloquean la entrega mientras el equipo investiga la inestabilidad.
• Pruebas asíncronas ejercen flujos de trabajo más amplios, composiciones de etapa completa o infraestructura costosa después de que el commit haya superado la puerta rápida.

Esto es más útil que discutir si cada prueba debe ser "en CI". La pregunta correcta es si una prueba es confiable y valiosa lo suficiente para influir en una decisión de promoción particular.

Regla práctica: Bloquee en evidencia de integración estable, no en la existencia de un conjunto de integración.

La implementación restante sigue de esa regla. Utilice dependencias similares a la producción donde una interfaz puede fallar, paralice comprobaciones independientes, mida falsas fallas y defina condiciones explícitas para la cuarentena y la promoción. Los equipos que buscan conectar este trabajo a una práctica de entrega más amplia también pueden revisar los beneficios de la integración continua.

Dónde se ubican las pruebas de integración entre las unitarias y las de extremo a extremo

La pirámide de pruebas es un modelo de costo, no una ley rigida. Las pruebas unitarias son rápidas porque aislán una función, clase o módulo. Esa velocidad las hace ideales para obtener feedback inmediato, pero los mocks pueden ocultar precisamente las fallas que ocurren en las juntas del sistema, como las diferencias de serialización, las restricciones de la base de datos, la configuración de autenticación o el comportamiento de la cola.

Las pruebas de extremo a extremo ocupan la posición opuesta. Ejercen el recorrido del usuario a lo largo de la pila completa, lo que las hace valiosas para flujos de trabajo de alto riesgo. También cruzan navegadores, redes, servicios e infraestructuras, por lo que el diagnóstico y la estabilidad se vuelven más difíciles. Si cada merge espera a que se complete todo el estado de extremo a extremo, los desarrolladores obtienen un señal lento que a menudo les dice menos que una prueba de integración focalizada a nivel de API.

Las pruebas de integración ocupan el terreno intermedio. Utilizan dependencias reales o casi reales para verificar el comportamiento de servicio a servicio sin requerir una orquestación de UI completa. El nivel puede cubrir llamadas HTTP y gRPC, publicación de colas, migraciones de base de datos, interacción con caché y compatibilidad de esquema.

Patrones de integración útiles

Inicios de prueba de componentes en proceso con Testcontainers Iniciar el componente de la aplicación junto con dependencias como PostgreSQL, Redis o Kafka. Este patrón vale la pena el costo de configuración cuando el riesgo de defectos involucra persistencia, serialización, transacciones o semántica de corredor. Proporciona a la prueba una dependencia real mientras mantiene la frontera de la prueba estrecha.

Pruebas de contrato entre servicios con Pacto o un registro de esquemas Enfóquese en el acuerdo entre un consumidor y un proveedor. Son una buena opción cuando los equipos lanzan servicios independientemente y necesitan feedback rápido sobre el desplazamiento del contrato. Las pruebas de contrato no deben sustituir las pruebas de integración de comportamiento, pero pueden prevenir que un interfaz incompatible alcance un entorno compartido.

API-niveles de prueba contra una pila de staging compuesta Llame a varios servicios desplegados a través de sus rutas de red reales. Utilice este patrón para flujos de trabajo donde la ruta, la autenticación, el descubrimiento de servicios, la configuración de despliegue o la política de infraestructura importan. Mantenga el conjunto enfocado en rutas críticas comerciales, porque una pila de staging completa cuesta más provisionar y es más difícil aislar cuando falla.

Mantenga deliberadamente el conjunto de fusión sincrónico estrecho. Un objetivo práctico es mantener el camino de integración menos de 10 minutos por commit de fusiónentonces mueva escenarios expansivos a la ejecución asíncrona. los equipos que desean una base más amplia para esta división pueden revisar¿qué incluye la prueba automatizada?

pero el principio gobernante sigue siendo simple: paga por la realidad donde cambia una decisión de lanzamiento.

Gestión de entornos y datos para pruebas fieles una prueba que se ejecuta contra el entorno incorrecto puede producir confianza falsa. Una prueba que se ejecuta contra un entorno compartido inestable puede producir falsas fallas. Fiable pruebas de integración de CI/CD necesitan una estrategia de entorno que haga explícita la frontera de dependencia y el estado de datos reproducible.

Comience con dependencias que se pueden ejecutar con fe. Testcontainers puede proporcionar instancias de PostgreSQL, Redis y Kafka desechables para cada trabajo. El beneficio clave no es Docker en sí mismo. Es el control sobre versiones, configuración, inicio y finalización.

una secuencia de trabajo reproducible

utilice una secuencia fija en lugar de dejar que la prueba code improvise su configuración:

1. Inicia dependencias. Inicia el contenedor PostgreSQL, luego espera a que se realice una verificación de salud real en lugar de asumir que un proceso en ejecución está listo para aceptar tráfico.
2. Aplica migraciones. Ejecuta el mismo camino de migración utilizado por la aplicación. No cree un esquema de prueba manualmente que pueda desviarse de la producción.
3. Carga fixtures deterministas. Sembra solo los registros necesarios para el escenario, y da a cada trabajo datos aislados para que los ejecuciones paralelas no puedan mutar el estado de uno a otro.
4. Ejecuta afirmaciones de contrato. Verifica formatos de solicitud, comportamiento de respuesta, esquemas de eventos, transiciones de estado y resultados de persistencia.
5. Desmonta todo. Destruye contenedores y volúmenes temporales incluso cuando una prueba falla, para que las pruebas posteriores no hereden un estado corrupto.

Un arranque de PostgreSQL de 90 segundos puede ser un costo razonable cuando detecta defectos de migración y transacciones. Un clúster de staging completo es una decisión diferente. Consumir más infraestructura, introduce más desplazamiento de configuración y aumenta el número de lugares donde una falla puede originarse. Comienza con el entorno más estrecho fiel, luego amplíalo cuando la cobertura de contrato o incidentes de producción muestren que el límite más pequeño está omitiendo un modo de falla significativo.

Utiliza virtualización con intención.

Algunos sistemas de terceros no pueden provisionarse de manera segura en cada pipeline. WireMock, Mountebank y Hoverfly pueden simular esas dependencias, pero la simulación debe tratarse como un contrato mantenido, no como una escapatoria conveniente. Un mock que devuelve solo respuestas ideales no revelará la expiración de la autenticación, la limitación de velocidad, los payloads malformados, el manejo de tiempos de espera o la evolución del esquema.

Los entornos de visualización ephemeris son útiles cuando el riesgo depende de varios servicios desplegados que trabajan juntos. Docker Compose puede proporcionar una composición local y de CI compacta, mientras que los nombres de espacio de Kubernetes pueden aislar los entornos de solicitud de revisión cuando se necesita probar el comportamiento de la implementación. Independientemente del enfoque que utilices, pin las versiones de dependencia y registre la configuración utilizada por cada ejecución.

Los secretos necesitan la misma disciplina que los datos. Almacene las credenciales fuera de los conjuntos de pruebas y rotule el acceso a través de los mecanismos protegidos de la plataforma. El Capgo guide to managing secrets in CI/CD pipelines proporciona orientación relevante para mantener valores sensibles fuera de la configuración del repositorio.

Un breve recorrido visual puede ayudar a los equipos a alinearse en el ciclo de vida del entorno:

Ejemplos de pipeline para Acciones de GitHub, GitLab CI y Jenkins

Lo que importa menos es el ejecutor que la forma de la flujo de trabajo. Construya una vez, proporcione dependencias predecibles, divida grupos de pruebas independientes, publique resultados legibles por máquinas y haga obvio el límite bloqueante. El cambio de sintaxis se produce a través de las plataformas, pero esas reglas de operación permanecen consistentes.

Acciones de GitHub

A una matriz funciona bien cuando los pruebas de integración pueden ser divididas por dominio o shard. Los contenedores de servicios mantienen las dependencias cerca del ejecutor, mientras que la salida de JUnit proporciona a las solicitudes de extracción y los sistemas downstream un formato de resultado estable.

name: integration

on:
  pull_request:

jobs:
  integration:
    strategy:
      fail-fast: false
      matrix:
        suite: [billing, orders, notifications]
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: app_test
        options: >-
          --health-cmd "pg_isready -U postgres -d app_test"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 12
      redis:
        image: redis:7
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run test:integration, --suite=${{ matrix.suite }}
      - if: always()
        uses: actions/upload-artifact@v4
        with:
          name: junit-${{ matrix.suite }}
          path: test-results/*.xml

Pegar las versiones de acción y dependencia reduce la deriva del entorno. GitHub Acciones expone la paralelización principalmente a través de matrices y trabajos separados, por lo que utilice una matriz solo cuando cada shard tenga datos aislados y duración predecible.

GitLab CI

GitLab CI puede separar la preparación, la ejecución de las pruebas y la informe. Las pipelines hijo son útiles cuando un gran repositorio posee múltiples servicios con diferentes entornos de integración. Los artefactos preservan los resultados de JUnit incluso cuando el trabajo de prueba falla.

stages:
  - build
  - integration

build-image:
  stage: build
  script:
    - docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

integration:
  stage: integration
  parallel:
    matrix:
      - SUITE: [billing, orders, notifications]
  image: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  services:
    - name: postgres:16
      alias: postgres
    - name: redis:7
      alias: redis
  script:
    - ./scripts/migrate-test-db.sh
    - npm run test:integration, --suite="$SUITE" --reporter=junit
  artifacts:
    when: always
    reports:
      junit: test-results/*.xml

Utilice las pipelines hijo de GitLab cuando la propiedad de servicio o la topología de despliegue hace que un archivo monolítico sea difícil de mantener. Mantenga la pipeline padre responsable de la decisión de promoción, de lo contrario un hijo individual puede pasar mientras el señal de lanzamiento general sigue siendo ambigua.

Jenkins

Jenkins es útil cuando los equipos necesitan agentes autoalojados o acceso a la red inusual. Un archivo de Jenkinsfile declarativo puede asignar agentes basados en Docker y ejecutar conjuntos en paralelo, pero el equipo es responsable de la mantenimiento de los plugins, el controlador, el agente e imagen.

pipeline {
  agent none

  stages {
    stage('Build') {
      agent { docker 'node:22' }
      steps {
        sh 'npm ci'
        sh 'npm run build'
        stash name: 'build', includes: 'dist/**'
      }
    }

    stage('Integration') {
      parallel {
        stage('Billing') {
          agent { docker 'my-org/integration-runner:stable' }
          steps {
            unstash 'build'
            sh './scripts/start-test-dependencies.sh'
            sh 'npm run test:integration, --suite=billing'
          }
        }
        stage('Orders') {
          agent { docker 'my-org/integration-runner:stable' }
          steps {
            unstash 'build'
            sh './scripts/start-test-dependencies.sh'
            sh 'npm run test:integration, --suite=orders'
          }
        }
      }
    }
  }

  post {
    always {
      junit 'test-results/*.xml'
    }
  }
}

Para equipos que ya utilizan GitHub La construcción y liberación automatizada con GitHub Actions pueden proporcionar un patrón de despliegue útil. La importante elección de diseño sigue siendo la misma en todos los tres ejecutores: no convierta cada prueba cara a cara costosa en un bloqueador de fusión síncrono.

Tácticas de confiabilidad para pruebas de integración inestables

Los intentos de repetición son útiles para el diagnóstico, pero los intentos de repetición generalizados son una mala estrategia de confiabilidad. Pueden convertir un defecto real en un resultado verde, ocultar la inestabilidad del entorno y hacer que las tablas de pasos parezcan más saludables de lo que realmente es el pipeline.

La escala del problema es visible en los datos de ingeniería publicados. Google informó aproximadamente 16% de las pruebas con algún grado de inestabilidad y sobre 1,5% de todas las ejecuciones de pruebas devolviendo un resultado inestable, mientras que otro estudio encontró que 4,56% de las fallas de prueba de Google se debieron a pruebas inestables, como se resume en la orientación de la prueba de integración y entrega continua de AWS. Los datos de Google también mostraron sobre 84% de las transiciones CI de paso a falla eran inestables en lugar de verdaderos errores, y los proyectos de Microsoft informaron sobre 4,6% pruebas inestables Según una investigación, según la revisión de estadísticas de pruebas inestables de Panto.

Medir antes de cambiar la política

Seguir la inestabilidad como:

fracaso inestable ÷ ejecuciones totales × 100

Usar un ventana de 7 a 30 díasy calcularlo por suite, prueba, imagen de ejecución, dependencia y entorno. Una prueba que falla solo en un ejecutor es un problema de remedio diferente a una prueba que falla en todos los entornos.

Usar estas categorías de triaje:

• Falla del producto: bloquear la puerta relevante y reparar el code o contrato.
• Fallas del entorno: Reparar verificaciones de salud, límites de recursos, red, o configuración de dependencias.
• Fallas de prueba: Corregir el orden de las afirmaciones, estado compartido, tiempo, limpieza, o diseño de fijaciones.
• Estabilidad no clasificada: Quedarse temporalmente en cuarentena, pero asignar un propietario y una fecha de vencimiento.

Eliminar las causas usuales

El estado mutable compartido crea dependencia de orden. Proporcionar a cada trabajo esquemas aislados, identificadores únicos, o un límite de transacción de rollback. Los sistemas asíncronos necesitan una supervisión condicional con límites de tiempo, no sueños arbitrarios. Inyectar relojes en la lógica de expiración, y esperar a que el contenedor esté sano en lugar de la inicialización del proceso.

La fragmentación reduce el tiempo en el reloj de pared, pero no arregla una prueba mala. Ejecutar fragmentos de manera independiente, preservar registros para cada fragmento, y volver a ejecutar solo la prueba fallida o el fragmento para el diagnóstico. No vuelva a ejecutar todo el pipeline solo porque una comprobación de integración tuvo una falla del entorno.

Una prueba puede salir de la cuarentena solo después de satisfacer una política de estabilidad definida, como ejecuciones verdes consecutivas a lo largo de los entornos donde se ejecutará. El umbral exacto debe ser elegido por el equipo y registrado en la política. La parte importante es que la promoción se gana a través de la estabilidad observada, no eliminando la etiqueta de cuarentena.

Políticas de control de calidad y reglas de promoción de despliegue

Una puerta de control de calidad debe responder a una pregunta: ¿tiene este artefacto suficientes evidencias confiables para moverse al siguiente entorno? No debe convertirse en un vertedero para cada prueba que la organización ha acumulado.

La brecha de cumplimiento es una advertencia. Un sondeo de 2025 citado por Análisis de pruebas de Testkube de CI/CD informa que 72% de las organizaciones han automatizado la QA en CI/CD, mientras que solo 26% aplican controles de calidad que bloquean la implementación cuando las pruebas fallan. La adopción sin cumplimiento deja la decisión de liberación a la memoria, la urgencia o una lista de verificación manual.

Utilice controles de etapa específica

En el momento de la comitación, bloquee las pruebas unitarias rápidas y el conjunto de integración estable que protege las interfaces modificadas o críticas. En la etapa de staging, agregue verificaciones más amplias de entornos compuestos y validación de la configuración de despliegue. Antes de la producción, requiera el artefacto aprobado, la validación exitosa del entorno protegido y una aprobación explícita donde su modelo de riesgo lo requiera.

No confundas la 'tasa de paso' con un porcentaje objetivo bruto. Un conjunto puede mostrar una alta tasa de paso mientras falla repetidamente en el camino de pago o autenticación exacto que importa. Define la cobertura del camino crítico por comportamiento, luego requiere que esas comprobaciones pasen de manera determinista.

Haz visibles los saltos

Configura la protección de rama para que una comprobación de bloqueo fallida impida la fusión. Configura las reglas de protección de entorno para que la promoción requiera las aprobaciones y artefactos esperados. Un override humano puede ser necesario durante un incidente, pero debe requerir una razón explícita, un aprobador nombrado, una fecha y un ticket de seguimiento.

La cuarentena no es permiso para ignorar las fallas. Es una forma controlada de mantener el envío en movimiento mientras se preserva la evidencia. Si un test cuarentizado cubre un camino de liberación protegido, la política debe restaurarlo a estado de bloqueo o requerir una decisión de riesgo antes de la promoción.

Lista de verificación de adopción y Observabilidad para la confianza a largo plazo

Los equipos suelen fallar en la prueba de integración de una de dos maneras. Comienzan con un conjunto enorme que ralentiza cada fusión, o crean un conjunto rápido con mocks tan amplios que nunca ejercen las fallas que expone la producción. Un plan de adopción en etapas evita ambos trampas.

Primera fase, haga que el señal existente sea confiable

Comience con el pipeline que ya tiene:

• Establezca la primera puerta: Identifique contratos de servicios críticos y haga solo comprobaciones estables bloqueantes.
• Defina el comportamiento de reintento: Permita reintentos dirigidos para el diagnóstico, nunca reintentos silenciosos que conviertan la falla en éxito.
• Habilite la paralelización: Divida los conjuntos por dominio limitado, dependencia o shard, con datos aislados por trabajo.
• Publique los resultados de las pruebas: Almacene informes JUnit, registros, estado de contenedor y clasificación de fallas para cada ejecución.

En esta etapa, no busque la cobertura máxima. Elimine las fuentes más costosas de ruido primero, luego utilice la confianza recuperada del desarrollador para ampliar la cobertura real de dependencias.

Segunda fase, aumente la fidelidad del entorno

Agregar Testcontainers para dependencias que son baratas de reproducir. Introducir pruebas de contrato donde la propiedad de servicio está distribuida. Utilizar entornos ephemeris cuando la ruta, la configuración de despliegue o el comportamiento entre servicios no pueden representarse con precisión en un trabajo compacto.

La decisión de selección debe basarse en evidencia. Si un incidente de producción expuso una desincronización de migración, agregar un camino de base de datos real. Si un API se desplazó entre servicios independientemente desplegados, agregar un contrato de proveedor-consumidor. Si una falla depende de la configuración de Kubernetes, ejecutar la verificación relevante contra un espacio de nombres ephemeris en lugar de fingir que un mock prueba lo mismo.

Fase tres, conectar observabilidad a la triage

Captura Porcentajes de duración de prueba, diferencias de configuración de entorno, versiones de dependencia bloqueadas, ratios de reintentos para pasar y registros y trazas de aplicación correlacionados a través de OpenTelemetry. Un dashboard útil debería mostrar:

• Aumento de la tasa de flake: ¿Qué suites y pruebas se están volviendo menos deterministas?
• Tiempo medio para pasar verde: ¿Dónde un pipeline fallido pasa tiempo antes de la recuperación?
• Cúmulos de modos de falla: ¿Si las fallas se agrupan alrededor de code, entorno, dependencia o diseño de prueba?
• Efectivo de inventario: ¿Qué pruebas están en cuarentena, quién las posee y cuándo deben ser revisadas.
• Evidencia de promoción: ¿Qué controles pasaron antes de cada cambio de entorno?

Esta es la interpretación operativa de observabilidad de la aplicación. La consola no es un archivo retrospectivo. Debe cambiar la decisión de hoy sobre si una prueba bloquea, espera asincrónicamente o regresa a la cuarentena.

Considere mantener una política de una página con el conjunto bloqueante, las reglas de cuarentena, la propiedad del entorno, los límites de reintento, los requisitos de artefactos y el proceso de sobrescritura. Revisarla cuando cambian los datos de falla, no solo cuando un incidente importante fuerza la conversación.

Capgo proporciona integraciones CI/CD para automatizar la carga de paquetes de actualización en vivo firmados después de una compilación web, con canales que pueden apoyar flujos de trabajo de rama de características, de staging y de producción. Si su equipo de CapacitorJS o Electron necesita conectar evidencia de prueba de integración a la entrega móvil controlada, visite Capgo para evaluar el API y el flujo de trabajo de despliegue.