Skip to content

Proceso de Desarrollo

Jump to bottom
Arturo Gomez edited this page Jun 13, 2026 · 1 revision

Proceso de Desarrollo — Kairo

Versión: v1.2.0  |  Fecha: 2026-06-13
Este documento describe el proceso de desarrollo de software del equipo Kairo, desde la captura de requisitos hasta el mantenimiento en producción.

Diagrama de Actividad UML

flowchart TD
    START(( )) --> REQ

    %% ── REQUIREMENTS ──────────────────────────────────────────
    subgraph REQUIREMENTS["📋 Requirements"]
        REQ["Captura de requisitos\n(issues, feedback, backlog)"]
        REQ --> STORIES["Redactar User Stories\ny criterios de aceptación"]
        STORIES --> PRIORITY["Priorizar en backlog\ncon story points"]
    end

    PRIORITY --> PLAN

    %% ── SPRINT PLANNING ────────────────────────────────────────
    subgraph SPRINT_PLAN["📅 Sprint Planning"]
        PLAN["Crear Sprint en Kairo\n(nombre, fechas, objetivo)"]
        PLAN --> ASSIGN["Asignar tareas\na miembros del equipo"]
        ASSIGN --> ACTIVATE["Activar Sprint\n→ estado ACTIVE"]
    end

    ACTIVATE --> DESIGN

    %% ── DESIGN ─────────────────────────────────────────────────
    subgraph DESIGN["🎨 Design"]
        direction TB
        DB["Diseño de esquema\nOracle DB"]
        API_D["Diseño de contratos\nAPI REST"]
        UI["Diseño de interfaz\nReact UI / UX"]
        DB --- API_D --- UI
    end

    DESIGN --> DEV

    %% ── DEVELOPMENT ─────────────────────────────────────────────
    subgraph DEV["💻 Development"]
        direction TB
        BACK["Backend\nSpring Boot + JPA"]
        FRONT["Frontend\nReact + Vite"]
        BOT["Kairo Bot\nTelegram long-polling"]
        BACK --- FRONT --- BOT
    end

    DEV --> BRANCH["Crear rama de feature\nfeat/ · fix/ · hotfix/"]
    BRANCH --> PR["Abrir Pull Request\nhacia main"]
    PR --> REVIEW{"Code Review\naprobado?"}

    REVIEW -- "❌ Cambios\nsolicitados" --> DEV
    REVIEW -- "✅ Aprobado" --> CI

    %% ── CI ──────────────────────────────────────────────────────
    subgraph CI["⚙️ CI — GitHub Actions"]
        BUILD["Maven build\n+ compilar frontend"]
        BUILD --> TESTS["Ejecutar tests\nautomatizados"]
        TESTS --> DOCKER["Construir imagen\nDocker"]
    end

    CI --> CI_OK{"Pipeline\npasó?"}
    CI_OK -- "❌ Falló" --> DEV
    CI_OK -- "✅ Verde" --> MERGE["Merge a main\n+ tag de release"]

    %% ── DEPLOYMENT ──────────────────────────────────────────────
    MERGE --> DEPLOY

    subgraph DEPLOY["🚀 Deployment — OCI"]
        DOWN["docker compose down"]
        DOWN --> PULL["docker compose pull\n(nueva imagen)"]
        PULL --> UP["docker compose up -d\n(contenedor en background)"]
    end

    DEPLOY --> VERIFY{"Verificación\nen producción"}
    VERIFY -- "❌ Error detectado" --> ROLLBACK["Ejecutar workflow\nde rollback\n(SHA anterior)"]
    ROLLBACK --> DEV
    VERIFY -- "✅ Funciona" --> DONE_TASK["Marcar tarea DONE\n+ registrar horas reales"]

    %% ── SPRINT CLOSE ────────────────────────────────────────────
    DONE_TASK --> SPRINT_END{"¿Todas las\ntareas DONE?"}
    SPRINT_END -- "No" --> DEV
    SPRINT_END -- "Sí" --> CLOSE_SPRINT["Cerrar Sprint\n→ estado CLOSED"]

    %% ── MAINTENANCE ─────────────────────────────────────────────
    CLOSE_SPRINT --> MAINTENANCE

    subgraph MAINTENANCE["🔧 Maintenance"]
        RETRO["Sprint Retrospective\n+ Review de métricas\n(Dashboard KPIs)"]
        RETRO --> MONITOR["Monitoreo de producción\n(logs, notificaciones)"]
        MONITOR --> HOTFIX{"¿Hotfix\nnecesario?"}
        HOTFIX -- "Sí" --> HFIX["Crear rama hotfix/\ny aplicar fix urgente"]
        HFIX --> PR
        HOTFIX -- "No" --> NEXT["Planear siguiente\nSprint"]
    end

    NEXT --> REQ

    END(( )) 
    MAINTENANCE --> END

    %% ── ESTILOS ─────────────────────────────────────────────────
    style START fill:#000,stroke:#000,color:#fff
    style END fill:#000,stroke:#000,color:#fff,stroke-width:4px
    style REQUIREMENTS fill:#e8f4fd,stroke:#2196F3
    style SPRINT_PLAN fill:#e8f5e9,stroke:#4CAF50
    style DESIGN fill:#fff3e0,stroke:#FF9800
    style DEV fill:#f3e5f5,stroke:#9C27B0
    style CI fill:#fce4ec,stroke:#E91E63
    style DEPLOY fill:#e0f2f1,stroke:#009688
    style MAINTENANCE fill:#fff8e1,stroke:#FFC107
Loading

Descripción del proceso por fase

1. Requirements

El ciclo inicia con la captura de necesidades del cliente o del equipo. Los requisitos se traducen en User Stories con criterios de aceptación claros y se priorizan en el backlog con story points. Herramientas: GitHub Issues, reuniones de equipo.

2. Sprint Planning

El Manager crea un Sprint en Kairo, define el objetivo y las fechas. Las tareas del backlog se asignan a los miembros del equipo. El sprint se activa formalmente al iniciar el período de trabajo.

3. Design

Actividad paralela que define:

  • Esquema de base de datos — tablas, relaciones, constraints en Oracle DB.
  • Contratos de API REST — endpoints, DTOs, códigos de respuesta (documentados en Swagger/OpenAPI).
  • Interfaz de usuario — wireframes y componentes React.

4. Development

Desarrollo simultáneo de los tres componentes del sistema:

  • Backend (Spring Boot, JPA, MapStruct, Spring Security + JWT)
  • Frontend (React + Vite, componentes funcionales)
  • Kairo Bot (módulo de Telegram dentro del monolito, long-polling)

Cada feature se desarrolla en una rama independiente siguiendo la convención feat/, fix/, o hotfix/.

5. Code Review (Pull Request)

Al terminar el desarrollo, se abre un PR hacia main. Otro miembro del equipo revisa:

  • Correctitud lógica y de negocio
  • Adherencia a la arquitectura en capas
  • Cobertura de casos borde y validaciones

Si hay cambios solicitados, el desarrollador vuelve a la fase de desarrollo.

6. CI — GitHub Actions

Al aprobar el PR, el pipeline automático ejecuta:

  1. Maven build + compilación del frontend con Vite
  2. Tests automatizados (unitarios e integración)
  3. Construcción de imagen Docker con la nueva versión

Si alguno falla, el merge se bloquea y se regresa a desarrollo.

7. Deployment — OCI

Con el pipeline verde, se hace merge a main y se publica un tag de release (ej. v1.2.0). El deploy en OCI ejecuta:

docker compose down
docker compose pull   # descarga la nueva imagen
docker compose up -d  # levanta el stack actualizado

Si se detecta un error en producción, el workflow de rollback restaura la imagen del SHA anterior automáticamente.

8. Task Closure

Una vez verificado en producción, cada tarea se marca como DONE en Kairo registrando las horas reales trabajadas — dato que alimenta las métricas del Dashboard.

9. Sprint Close & Maintenance

Al concluir el sprint, el Manager lo cierra. El equipo realiza una retrospectiva revisando los KPIs del Dashboard (velocity, eficiencia, horas por developer). Se monitorea producción de forma continua; si se detecta un bug crítico, se abre un hotfix/ que entra directamente al flujo de PR → CI → Deploy.

Tecnologías por fase

Fase Herramientas
Requirements & Planning GitHub Issues · Kairo (sprints y tareas)
Design Diagramas C4/DSL · Swagger/OpenAPI · Figma (wireframes)
Development IntelliJ IDEA · VS Code · Java 17 · React 18 · Maven
Version Control Git · GitHub (ramas, PRs, code review)
CI/CD GitHub Actions · Docker · Maven Wrapper
Deployment OCI Compute · Docker Compose · Contenedor único (monolito)
Monitoring Logs de Docker · NOTIFICATION_LOG · Dashboard de Kairo
Rollback GitHub Actions workflow (rollback.yml) con SHA de 7 caracteres

Convenciones de ramas

Prefijo Uso
feat/ Nueva funcionalidad
fix/ Corrección de bug no crítico
hotfix/ Corrección urgente en producción
refactor/ Mejora interna sin cambio de comportamiento
test/ Cambios exclusivamente de tests
ci/ Cambios en pipelines de CI/CD
docs/ Documentación únicamente

Página mantenida por el equipo Kairo. Última actualización: v1.2.0 — 2026-06-13.

Kairo

Inicio
Guía de Usuario

Primeros pasos

Guías de uso

Infraestructura

Referencia

Clone this wiki locally