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

A payment service change can pass thousands of unit tests and still break production because the billing API interprets an idempotency key differently than the service expects. The failure may sit unnoticed until a nightly integration job reaches the interface, long after the commit has moved through the fast part of the pipeline.

El cambio en un servicio de pago puede pasar miles de pruebas unitarias y aún así romper la producción porque el servicio de facturación __CAPGO_KEEP_0__ 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. 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 debe 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 mainstream. 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 de integración útiles
• Gestionar entornos y datos para pruebas fieles
  • Una secuencia de trabajo reproducible
  • Usar virtualización con intención
• Ejemplos de pipeline para acciones de GitHub, 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 el señal existente
  • Fase dos, aumentar la fidelidad del entorno
  • Fase tres, conectar observabilidad a la triage

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

La integración de pruebas es donde el riesgo de liberación se vuelve concreto. Una prueba 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. Debería ganar promoción produciendo evidencia confiable de que las interfaces que cambia siguen funcionando en una disposición similar a la producción.

La distinción importa porque la integración frecuente sin verificación automática solo mueve los defectos más rápido. Una revisión sistemática de las aproximaciones de mejora de CI/CD identificó prioridades recurrentes que incluyen reducir el tiempo de compilación y prueba, mejorar la visibilidad en los resultados, apoyar la prueba continua, detectar fallas y mejorar la confiabilidad de la implementación. Otra revisión en el mismo registro de investigación define la integración continua alrededor de la integración frecuente code verificada por un compilado automático que incluye pruebas, por lo que los defectos pueden detectarse rápidamente.

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 siguen siendo 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 staging completas 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 como 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 fronteras de navegador, red, servicio e infraestructura, por lo que el diagnóstico y la estabilidad se vuelven más difíciles. Si cada merge espera a que toda la propiedad de extremo a extremo esté lista, los desarrolladores obtienen un señal lento que a menudo les dice menos que una prueba de integración a nivel de API enfocada.

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 cola, 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 una interfaz incompatible de llegar a 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 para provisionar y es más difícil de 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

un diagrama que ilustra tres pasos para gestionar entornos y datos para garantizar pruebas de integración de software fieles.

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 un chequeo de salud real se realice en lugar de suponer 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 mantenido que puede 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. Desarma 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ía más infraestructura, introduciría más desplazamiento de configuración y aumentaría el número de lugares donde un error 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 escapada conveniente. Un mock que devuelve solo respuestas ideales no revelará la expiración de la autenticación, el límite de velocidad, los payloads malformados, el manejo de tiempos de espera o la evolución de la 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 cambios 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 fijos de prueba 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 del 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 las 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 secundarias 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 secundarias de GitLab cuando la propiedad de los servicios o la topología de despliegue hace que un archivo monolítico sea difícil de mantener. Mantenga la pipeline principal responsable de la decisión de promoción, de lo contrario un hijo individual puede pasar mientras el señal de liberación general sigue siendo ambigua.

Jenkins

Jenkins es útil cuando los equipos necesitan agentes autoadministrados 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 están utilizando GitHub La automatización de compilación y lanzamiento con GitHub Actions Puede 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 en un bloqueador de fusión síncrono costoso.

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

Los intentos de conexión son útiles para el diagnóstico, pero los intentos de conexión generales 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 de tasa de éxito 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 cierta 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 de CI de paso a fallo 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 de una prueba que falla en todos los entornos.

Usar estas categorías de triaje:

• Falla del producto: bloquear la puerta relevante y arreglar 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 un monitoreo condicional con tiempos de espera acotados, 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 volver a ejecutar todo el pipeline solo porque una comprobación de integración tuvo una falla del entorno.

Una prueba solo puede salir de la cuarentena 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 pruebas 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íficos

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 entorno compuesto y validación de la configuración de implementación. 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. Una suite 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 bypasses

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 la entrega 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 una suite enorme que ralentiza cada fusión, o crean una suite rápida 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 persiga 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 incompatibilidad de migración, agregar un camino de base de datos real. Si un API se desplazó entre servicios desplegados de manera independiente, 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 pruebadiferencias 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:

• Consumo de tasa de flake: ¿Cuáles suites y pruebas se están volviendo menos deterministas?
• Tiempo medio para verde: ¿Dónde un pipeline fallido pasa tiempo antes de la recuperación?
• Clústeres de modos de falla: ¿Si las fallas se agrupan alrededor de code, entorno, dependencia o diseño de prueba?
• Almacenamiento en cuarentena: ¿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 la 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.

Mantenga una política de equipo 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. Revisela 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 la evidencia de prueba de integración a la entrega móvil controlada, visite Capgo a evaluar el API y el flujo de despliegue.