Ajustes fallo despliegue microcliente root

[edwargl7]

Se requiere realizar ajustes en el microcliente root que permita resolver fallos que no han permitido el correcto despliegue del microcliente en el ambiente de pruebas.

Sub Tareas

• [x] Ajustes en el microcliente root auditoria_plan_mejoramiento_root_mf.
• [ ] Pruebas funcionales.

Criterios de aceptación

• [x] Documentación ajustes requeridos, fallos encontrados y resultado pruebas funcionales.

Requerimientos

No aplica

Definition of Ready - DoR

• [x] Está refinada y estimada en puntos de historia por el equipo.
• [x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• [x] No tiene bloqueos que impidan su ejecución.
• [x] Las dependencias están identificadas y resueltas.
• [x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• [x] Desarrollo en local.
• [ ] Push en Feature.
• [x] Pruebas locales (funcionales).
• [ ] PR a Develop.
• [x] Criterios de aceptación cumplidos.
• [x] Documentación de issue realizada.
• [x] Aprobada por SM/Líder técnico.

[CristianCGutierrezG]

Se realiza una investigación del funcionamiento de Drone CI para entender el despliegue, usando como ejemplo el archivo drone.yml del root gestion_contractual_root_mf

Resumen del archivo drone.yml

El archivo de configuración define un pipeline que ejecuta diversas validaciones y despliegues en función de las ramas y eventos del repositorio:

1. Validaciones automáticas:

   • check_readme: Valida la existencia y el formato correcto del archivo README.md en ramas develop, feature/*, y release/*.
   • check_branch: Verifica que la rama tenga el nombre correcto y revisa la URL del repositorio.
   • check_commits: Comprueba el formato de los commits para asegurar estándares de calidad en el historial (fallos ignorados).

2. Análisis de calidad del código:

   • run_sonar_scanner: Utiliza SonarQube para analizar la calidad del código, excluyendo carpetas como node_modules y archivos de prueba .spec.ts.

3. Construcción del proyecto Angular:

   • nodejs_release: Ejecuta npm run build:test para entornos de prueba en ramas release/*.
   • nodejs_master: Ejecuta npm run build:prod para entornos de producción en la rama master.

4. Despliegue en Amazon S3:

   • publish_s3_release: Publica el build en el bucket argov2-cliente-root para las ramas release/*.
   • publish_s3_master: Publica el build en el bucket cliente-prod para la rama master.

5. Notificación en Telegram:

   • Se envía un mensaje de notificación a Telegram al finalizar un build (éxito o fallo), detallando la información del commit y el autor.

Recomendaciones para el despliegue de microfrontends en Angular

Para adaptar este pipeline a proyectos microfrontend en Angular, es necesario:

• Asegurar que los scripts de build (build:test y build:prod) estén definidos en package.json.
• Configurar correctamente las credenciales de AWS en los secretos de Drone para el despliegue a S3.
• Verificar que las configuraciones de SonarQube se adapten al proyecto (agregando sonar-project.properties si es necesario).
• Confirmar que las notificaciones de Telegram están habilitadas con los tokens correctos para monitoreo.

[edwargl7]

Se continuarán los ajustes requeridos una vez culminada la presentación al cliente.