Lapachos Lending : L2BDEV-1170/L2BDEV-1171 - Investigación de Mejores Prácticas para Pruebas Automatizadas en AWS

1. Herramientas AWS para CI/CD

• AWS CodePipeline: Orquestación de flujos de trabajo CI/CD para integrar cambios y despliegues automatizados.

• AWS CodeBuild: Ejecución de pruebas unitarias y de integración. Ideal para compilar y ejecutar proyectos.

• Otros Servicios Relacionados:

  • AWS Lambda: Uso como infraestructura efímera para ejecutar tareas específicas como pruebas ligeras.

  • AWS CloudFormation: Generación de entornos temporales para pruebas usando plantillas predefinidas.

2. Integración de pruebas en pipelines

• Pruebas E2E (End-to-End): Se configuran para ejecutar tests automatizados tras despliegues en staging. Herramientas como Cypress para el frontend, y Postman para validación de API en backend.

• Flujo recomendado:

  1. Detectar cambios en repositorios de GitHub.

  2. Ejecutar pruebas unitarias de backend antes del despliegue en staging.

  3. Ejecutar pruebas E2E después de desplegar la aplicación en staging usando datos reales y endpoints configurados.

3. Infraestructura efímera para pruebas

• EC2: Uso de instancias temporales para correr pruebas más pesadas con acceso a recursos dedicados.

• AWS Lambda: Ideal para pruebas rápidas y livianas sin necesidad de mantener instancias persistentes.

• Amazon ECS/Fargate: Contenedores como entornos de prueba temporales para asegurar consistencia entre despliegues.

4. Evaluación de costos y seguridad

• Costos:

  • Usar servicios bajo demanda (Lambda, EC2) para evitar costos innecesarios.

  • Aprovechar el sistema de pricing de AWS para servicios temporales como Fargate.

• Seguridad:

  • Roles IAM con permisos mínimos necesarios para ejecutar pruebas automatizadas.

  • Monitorizar accesos y cambios en pipelines con AWS CloudTrail.

5. Propuesta de pipeline CI/CD con integración de pruebas

Pipeline sugerido:

• Fase 1: Detectar cambios en GitHub.

• Fase 2: Ejecutar pruebas unitarias en CodeBuild (backend y frontend).

• Fase 3: Desplegar en staging.

• Fase 4: Ejecutar pruebas E2E en staging (Cypress interactuando con el backend real).

• Fase 5: Si todo pasa, desplegar en QA usando Amplify (frontend) y CodeDeploy (backend).

6. Checklist de Buenas Prácticas

• Seguridad:

  • Utilizar roles IAM específicos por pipeline.

  • Cifrar credenciales y claves con AWS Secrets Manager.

• Optimización de costos:

  • Uso de instancias bajo demanda para pruebas pesadas.

  • Configuración de tiempo límite en tareas de pruebas para evitar cargos innecesarios.

• Eficiencia:

  • Paralelización de pruebas en CodeBuild para reducir tiempos.

  • Uso de caché de dependencias para acelerar procesos.

7. Conclusiones y Recomendaciones

• Implementar herramientas AWS recomendadas.

• Seguir el pipeline propuesto para pruebas integradas y despliegues seguros.

• Adoptar la checklist como guía para futuros procesos.

Escenario Práctico

1. Caso 1: Cambios en el backend (rama qa) → Probar integración con el frontend (rama qa).

2. Caso 2: Cambios en el frontend (rama qa) → Probar integración con el backend (rama qa).

3. Caso 3: Si las pruebas pasan → Desplegar en ““definir ambiente” (ambos componentes).

Arquitectura Flexible Propuesta con Pipeline

• Fuente 1: Repo del backend → Monitorea ramas qa.

• Fuente 2: Repo del frontend → Monitorea rama qa.

• Regla de Trigger:

  • Si hay cambios en backend (rama qa):

    • Desplegar backend desde test+ frontend desde testen ambientes temporales.

  • Si hay cambios en frontend (rama qa):

    • Desplegar frontend desde test + backend desde test en ambientes temporales.

Paso a Paso Detallado

A. Cuando se haga un cambio en el Backend (Rama test)

1. Trigger: Merge a qaen el backend.

2. Pipeline:

   • Build Backend (test):

     • CodeBuild clona el backend desde test, ejecuta pruebas unitarias y despliega un stack temporal (ej: backend-temp-test).

   • Build Frontend (test):

     • CodeBuild clona el frontend desde test, inyecta la URL del backend temporal y despliega en un bucket S3 temporal.

   • Pruebas E2E:

     • Cypress valida la integración frontend (test) + backend (test).

3. Si las pruebas pasan:

   • Despliegue en “QA“:

     • Merge de test (backend) → rama qa.

     • Merge de test (frontend) → rama qa.

     • Despliegue automático en ambiente “QA“ usando las ramas qa.

B. Cuando Haces un Cambio en el Frontend (Rama test)

1. Trigger: Push a test en el frontend.

2. Pipeline:

   • Build Backend (test):

     • Usar backend desde test .

   • Build Frontend (test):

     • Despliegue en bucket S3 temporal con la URL del backend elegido.

   • Pruebas E2E:

     • Validar integración frontend (test) + backend (test).

3. Si las pruebas pasan:

   • Despliegue en “QA“:

     • Merge de test (backend) → rama qa.

     • Merge de test (frontend) → rama qa.

     • Despliegue automático en ambiente “QA“ usando las ramas qa.

Propuesta de automatización

Objetivo: Progresivamente incorporar este proceso a los desarrollos del sprint.

Ambiente efímero / Test - QA

Ventajas

• Reduce costos al no realizar despliegues con errores en los ambientes

• Ahorra tiempo de desarrollo

• Entornos limpios y con alto % de disminución de errores

• Prevención de errores