Fase de Análisis

📊 Fase de Análisis - Sistema de Aprobación Automática de Releases

Esta sección documenta el análisis detallado de requerimientos, la lógica de evaluación y los criterios de aceptación para el sistema PTMD-BDB, alineados con los objetivos de la Kata Middle Developer.

El Desafío

En el entorno de desarrollo del Banco de Bogotá, la optimización del ciclo de vida de software es clave. Se requiere una solución que automatice la aprobación de paso a producción para solicitudes estándar (rs), garantizando que solo el código que cumple con los más altos estándares de calidad y seguridad sea promovido automáticamente.

Objetivos de la Kata

Automatización Inteligente: Eliminar la intervención manual en releases que cumplen criterios definidos.
Trazabilidad Garantizada: Asegurar que cada cambio esté respaldado por un PR o historia de JIRA.
Gestión de Obsolescencia: Prevenir el despliegue de frameworks que representen un riesgo tecnológico por falta de soporte.

Requerimientos Funcionales (RF)

RF-001: Gestión de Solicitudes de Release

El sistema debe procesar solicitudes con los siguientes metadatos:

Fecha: Registro temporal de la solicitud.
Equipo: Identificación del equipo solicitante.
Tipo de Cambio: Categorización (rs -> Release, fx -> Hot Fix, cv -> Ciclo de Vida).
Descripción: Detalle del cambio (obligatorio para rs).
Referencia: Identificador de PR (GitHub) o historia de JIRA.
Métricas de Prueba: Porcentaje de cobertura detectado.
Stack Tecnológico: Listado de frameworks y bibliotecas con sus versiones.

RF-002: Motor de Aprobación Automática (Tipo `rs`)

Solo las solicitudes de tipo rs son elegibles para aprobación automática si cumplen simultáneamente:

Calidad: Cobertura de pruebas unitarias ≥ 80%.
Estructura: Presencia de descripción y validación exitosa de PR (vía API) o ticket JIRA.
Obsolescencia: Frameworks dentro de su ventana de soporte (últimas 4 versiones mayores o no marcados como EOL).

RF-003: Flujo de Aprobación Manual y Notificación

Si una solicitud rs falla en cualquier regla:

Se marca como PENDING.
Se notifica automáticamente al aprobador técnico vía email (SMTP).
Se requiere una justificación manual obligatoria para proceder.

Requerimientos No Funcionales (RNF)

RNF-001: Escalabilidad y Arquitectura

Aislamiento de responsabilidades mediante una arquitectura de microservicios.
Comunicación eficiente entre servicios mediante protocolos ligeros.

RNF-002: Observabilidad y Auditoría

Registro detallado (Audit Log) de cada cambio de estado y acción realizada.
Persistencia robusta en PostgreSQL para análisis histórico.

RNF-003: Usabilidad (UX)

Dashboard interactivo con visualización clara de estados y KPIs de rendimiento (tasa de aprobación, cobertura promedio).

Lógica de Evaluación (Motor de Reglas)

graph TD
    Start[Solicitud Recibida] --> TypeCheck{¿Tipo = rs?}
    TypeCheck -- No --> Manual[Revisión Manual / Pendiente]
    TypeCheck -- Sí --> Coverage{¿Cobertura >= 80%?}
    Coverage -- No --> Fail[Rechazo Auto / Notificación]
    Coverage -- Sí --> RefCheck{¿PR/JIRA Válido?}
    RefCheck -- No --> Fail
    RefCheck -- Sí --> StackCheck{¿Frameworks Soportados?}
    StackCheck -- No --> Fail
    StackCheck -- Sí --> AutoApprove[APROBACIÓN AUTOMÁTICA]

Matriz de Actores

Actor	Responsabilidad
Equipo de Desarrollo	Crea solicitudes, provee stack y cobertura.
Aprobador Técnico	Revisa releases pendientes, justifica aprobaciones manuales.
Sistema (Automático)	Ejecuta el motor de reglas, valida contra APIs externas (GitHub, endoflife.date).
Analista de Calidad	Monitorea KPIs de ciclo de vida en el Dashboard.

[!IMPORTANT] El cumplimiento estricto de estos requerimientos es la base para asegurar el éxito en la Kata y la estabilidad del entorno productivo.