in

Acelerar CI con AWS CodeBuild: Ejecución de prueba paralela ahora disponible | Servicios web de Amazon

Estoy emocionado de anunciar que AWS CodeBuild ahora admite la ejecución de la prueba paralela, por lo que puede ejecutar sus suites de prueba simultáneamente y reducir los tiempos de construcción significativamente.

Con El proyecto de demostración que escribí para esta publicaciónel tiempo de prueba total disminuyó de 35 minutos a seis minutos, incluido el tiempo para aprovisionar los entornos. Estas dos capturas de pantalla de la consola de gestión de AWS muestran la diferencia.

Ejecución secuencial de la suite de prueba

Ejecución paralela de la suite de prueba

Los tiempos de prueba muy largos plantean un desafío significativo al ejecutar la integración continua (IC) a escala. A medida que los proyectos crecen en la complejidad y el tamaño del equipo, el tiempo requerido para ejecutar suites de prueba integrales puede aumentar drásticamente, lo que lleva a tiempos de ejecución de tuberías prolongadas. Esto no solo retrasa la entrega de nuevas características y correcciones de errores, sino que también obstaculiza la productividad del desarrollador al obligarlos a esperar resultados de compilación antes de continuar con sus tareas. He experimentado tuberías que tardaron hasta 60 minutos en funcionar, solo para fallar en el último paso, lo que requiere una repetición completa y más retrasos. Estos largos ciclos pueden erosionar la confianza del desarrollador en el proceso de CI, contribuir a la frustración y, en última instancia, ralentizar todo el ciclo de entrega de software. Además, las pruebas de larga duración pueden conducir a la contención de recursos, al aumento de los costos debido a la potencia informática desperdiciada y una eficiencia general reducida del proceso de desarrollo.

Con la ejecución de pruebas paralelas en CodeBuild, ahora puede ejecutar sus pruebas simultáneamente en múltiples entornos de cómputo de compilación. Esta característica implementa un enfoque de fragmentación donde cada nodo de compilación ejecuta independientemente un subconjunto de su conjunto de pruebas. CodeBuild proporciona variables de entorno que identifican el número de nodo actual y el número total de nodos, que se utilizan para determinar qué pruebas debe ejecutarse cada nodo. No existe un nodo de compilación de control o coordinación entre nodos en el tiempo de compilación; cada nodo opera de forma independiente para ejecutar su parte asignada de sus pruebas.

Para habilitar la división de la prueba, configure la sección de faneut de lotes en su buildspec.xmlespecificando el nivel de paralelismo deseado y otros parámetros relevantes. Además, use la utilidad CodeBuild-Tests-Run en su paso de compilación, junto con los comandos de prueba apropiados y el método de división elegido.

Las pruebas se dividen en función de la estrategia de fragmentación que especifique. codebuild-tests-run Ofrece dos estrategias de fragmentación:

  • Igualdistribución. Esta estrategia clasifica los archivos de prueba alfabéticamente y los distribuye en fragmentos por igual en entornos de prueba paralelos. Los cambios en los nombres o la cantidad de archivos de prueba pueden reasignar archivos en fragmentos.
  • Estabilidad. Esta estrategia fija la distribución de pruebas en fragmentos mediante el uso de un algoritmo de hashing consistente. Mantiene las tareas existentes de archivo a shard cuando se agregan o eliminan archivos nuevos.

CodeBuild admite la fusión automática de los informes de prueba al ejecutar pruebas en paralelo. Con la fusión del informe de prueba automática, CodeBuild consolida los informes de pruebas en un solo resumen de prueba, simplificando el análisis de resultados. El informe fusionado incluye estados de aprobación/falla agregados, duraciones de la prueba y detalles de falla, reduciendo la necesidad de procesamiento de informes manuales. Puede ver los resultados fusionados en la consola CodeBuild, recuperarlos utilizando la interfaz de línea de comandos AWS (AWS CLI) o integrarlos con otras herramientas de informes para optimizar el análisis de pruebas.

Veamos cómo funciona
Permítanme demostrar cómo implementar pruebas paralelas en un proyecto. Para esta demostración, creé un proyecto de pitón muy básico con cientos de pruebas. Para acelerar las cosas, le pedí al desarrollador de Amazon Q en la línea de comando que creara un proyecto y 1.800 casos de prueba. Cada caso de prueba está en un archivo separado y tarda un segundo en completarse. Ejecutar todas las pruebas en una secuencia requiere 30 minutos, excluyendo el tiempo para aprovisionar el entorno.

En esta demostración, ejecuto la suite de prueba en diez entornos de cómputo en paralelo y mido cuánto tiempo lleva ejecutar la suite.

Para hacerlo, agregué un buildspec.yml Archivo a mi proyecto.

version: 0.2

batch:
  fast-fail: false
  build-fanout:
    parallelism: 10 # ten runtime environments 
    ignore-failure: false

phases:
  install:
    commands:
      - echo 'Installing Python dependencies'
      - dnf install -y python3 python3-pip
      - pip3 install --upgrade pip
      - pip3 install pytest
  build:
    commands:
      - echo 'Running Python Tests'
      - |
         codebuild-tests-run \
          --test-command 'python -m pytest --junitxml=report/test_report.xml' \
          --files-search "codebuild-glob-search 'tests/test_*.py'" \
          --sharding-strategy 'equal-distribution'
  post_build:
    commands:
      - echo "Test execution completed"

reports:
  pytest_reports:
    files:
      - "*.xml"
    base-directory: "report"
    file-format: JUNITXML 

Hay tres partes para resaltar en el archivo YAML.

Primero, hay un build-fanout sección debajo batch. El parallelism El comando le dice a CodeBuild cuántos entornos de prueba se ejecutarán en paralelo. El ignore-failure El comando indica si se puede ignorar la falla en cualquiera de las tareas de compilación de fanout.

Segundo, uso el preinstalado codebuild-tests-run ordenar ejecutar mis pruebas.

Este comando recibe la lista completa de archivos de prueba y decide cuál de las pruebas debe ejecutarse en el nodo actual.

  • Usar el sharding-strategy Argumento para elegir entre distribución igualmente distribuida o estable, como expliqué anteriormente.
  • Usar el files-search argumento para pasar todos los archivos que son candidatos para una ejecución. Recomendamos usar el proporcionado codebuild-glob-search comando por razones de rendimiento, pero cualquier herramienta de búsqueda de archivos, como encontrar (1)funcionará.
  • Paso el comando de prueba real para ejecutar en el fragmento con el test-command argumento.

Por último, el reports La sección instruye a CodeBuild que recopile y fusione los informes de prueba en cada nodo.

Luego, abro la consola CodeBuild para crear un proyecto y una configuración de compilación por lotes para este proyecto. No hay nada nuevo aquí, así que te ahorraré los detalles. La documentación tiene todos los detalles para comenzar. Las pruebas paralelas funcionan en compilaciones por lotes. Asegúrese de configurar su proyecto para ejecutarse en lotes.

Ahora, estoy listo para activar una ejecución de la suite de prueba. Puedo cometer un nuevo código en mi repositorio de GitHub o activar la compilación en la consola.

Después de unos minutos, veo un informe de estado de los diferentes pasos de la compilación; con un estado para cada entorno de prueba o fragmento.

Cuando se completa la prueba, selecciono el Informes pestaña para acceder a los informes de prueba fusionados.

El Informes La sección agrega todos los datos de prueba de todos los fragmentos y mantiene el historial de todas las compilaciones. Selecciono mi construcción más reciente en el Historial de informes Sección para acceder al informe detallado.

Como se esperaba, puedo ver el estado agregado y el individuo para cada uno de mis 1,800 casos de prueba. En esta demostración, todos están pasando, y el informe es verde.

Las 1.800 pruebas del proyecto de demostración tardan un segundo cada una para completar. Cuando ejecuto esta suite de prueba secuencialmente, tardó 35 minutos en completarse. Cuando ejecuto la suite de prueba en paralelo en diez entornos de cómputo, tardó seis minutos en completarse, incluido el tiempo para aprovisionar los entornos. La carrera paralela tomó el 17.9 por ciento de la hora de la ejecución secuencial. Los números reales variarán con sus proyectos.

Cosas adicionales que saber
Esta nueva capacidad es compatible con todos los marcos de prueba. La documentación incluye ejemplos para Django, Elixir, GO, Java (Maven), JavaScript (Jest), Kotlin, Phpunit, Pytest, Ruby (pepino) y Ruby (RSPEC).

Para marcos de prueba que no aceptan listas separadas por el espacio, el codebuild-tests-run CLI proporciona una alternativa flexible a través del CODEBUILD_CURRENT_SHARD_FILES Variable de entorno. Esta variable contiene una lista de rutas de archivos de prueba nuevas separadas para el fragmento de compilación actual. Puede usarlo para adaptarse a diferentes requisitos de marco de prueba y formatear nombres de archivos de prueba.

Puede personalizar aún más cómo las pruebas se dividen en entornos escribiendo su propio script de fragmentación y utilizando el CODEBUILD_BATCH_BUILD_IDENTIFIER Variable de entorno, que se establece automáticamente en cada compilación. Puede usar esta técnica para implementar la paralelización u optimización específica de marco.

Precios y disponibilidad
Con la ejecución de la prueba paralela, ahora puede completar sus suites de prueba en una fracción del tiempo previamente requerido, acelerando su ciclo de desarrollo y mejorando la productividad de su equipo.

La ejecución de la prueba paralela está disponible en los tres modos de cómputo ofrecidos por CodeBuild: bajo demanda, capacidad reservada y AWS Lambda Compute.

Esta capacidad está disponible hoy en todas las regiones de AWS donde se ofrece CodeBuild, sin un costo adicional más allá de los precios estándar de CodeBuild para los recursos de cómputo utilizados.

Te invito a probar la ejecución de la prueba paralela en CodeBuild hoy. Visite la documentación de AWS CodeBuild para obtener más información y comenzar a paralelizar sus pruebas.

– Seb

PD: Aquí está el aviso que usé para crear la aplicación de demostración y su conjunto de pruebas: «Estoy escribiendo una publicación de blog para anunciar pruebas paralelas de CodeBuild. Escriba una aplicación Python muy simple que tenga cientos de pruebas, cada prueba en un archivo de prueba separado. Cada prueba tarda un segundo en completar».


¿Cómo está el blog de noticias? Tomar esto Encuesta de 1 minuto!

(Este encuesta está alojado por una empresa externa. AWS maneja su información como se describe en el Aviso de privacidad de AWS. AWS será propietario de los datos recopilados a través de esta encuesta y no compartirá la información recopilada con los encuestados).

Fuente

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

GIPHY App Key not set. Please check settings

65525

Final Cut Pro para Mac Gains Integración de juegos de imagen y más

La última temporada 2 de la temporada 2 se estrena el 13 de abril en HBO y Max.

Neil Druckmann no se preocupa por los spoilers después de que anteriormente «me volaron en la cara»