Nexus - AI Task Orchestrator

27-build-performance-analysis
Procedimiento: Build Performance Analysis

Despliegue
1 plugin(s)
Titulo
Descripcion
Contenido Markdown
9448 caracteres
# Procedimiento: Build Performance Analysis

## Metadata
- **ID**: PROC-27
- **Frecuencia**: Mensual o cuando builds > 10 min
- **Duraci├│n estimada**: 30-45 min
- **Requiere**: Acceso a CI/CD, m├®tricas de builds
- **Dependencias**: PROC-23 (Pipeline Health)
- **Bloquea**: Ninguno
- **Agentes**: devops-engineer

---

## Objetivo

Analizar y optimizar tiempos de build:
1. Identificar etapas lentas del pipeline
2. Detectar oportunidades de cacheo
3. Optimizar paralelizaci├│n
4. Reducir tiempos de build en >20%

---

## Umbrales de Rendimiento

| Tipo de Build | Objetivo | Aceptable | Lento |
|---------------|----------|-----------|-------|
| PR/MR validation | <5 min | <10 min | >10 min |
| Build completo | <10 min | <15 min | >15 min |
| Build + Deploy | <15 min | <20 min | >20 min |
| Release | <20 min | <30 min | >30 min |

---

## Checklist Ejecutable

### 1. Recopilar M├®tricas de Builds

#### GitLab CI

```bash
# Duraci├│n de ├║ltimos 50 pipelines exitosos
curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "$GITLAB_URL/api/v4/projects/$PROJECT_ID/pipelines?status=success&per_page=50" | \
  jq '[.[] | .duration] | {
    avg: (add / length / 60),
    min: (min / 60),
    max: (max / 60),
    p90: (sort | .[length * 0.9 | floor] / 60)
  }'

# Duraci├│n por job
PIPELINE_ID="xxx"
curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "$GITLAB_URL/api/v4/projects/$PROJECT_ID/pipelines/$PIPELINE_ID/jobs" | \
  jq '.[] | {name, stage, duration: (.duration / 60), status}'
```

#### Azure DevOps

```bash
# Duraci├│n de builds
curl -s -H "Authorization: Basic $AUTH" \
  "https://dev.azure.com/$AZURE_ORG/$AZURE_PROJECT/_apis/build/builds?api-version=7.0&resultFilter=succeeded&\$top=50" | \
  jq '[.value[] | (.finishTime | fromdateiso8601) - (.startTime | fromdateiso8601)] | {
    avg: (add / length / 60),
    min: (min / 60),
    max: (max / 60)
  }'
```

- [ ] M├®tricas recopiladas
- [ ] Duraci├│n promedio: ___ min
- [ ] P90: ___ min

### 2. Identificar Etapas Lentas

```bash
# Breakdown por stage
curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "$GITLAB_URL/api/v4/projects/$PROJECT_ID/pipelines/$PIPELINE_ID/jobs" | \
  jq 'group_by(.stage) | map({
    stage: .[0].stage,
    total_duration: ([.[].duration] | add / 60),
    jobs: length
  }) | sort_by(-.total_duration)'
```

**Ejemplo de an├ílisis:**

| Stage | Duraci├│n | % del Total | Paralelo |
|-------|----------|-------------|----------|
| build | 5 min | 40% | No |
| test | 4 min | 32% | S├¡ (3 jobs) |
| docker | 2 min | 16% | No |
| deploy | 1.5 min | 12% | No |

- [ ] Etapa m├ís lenta identificada: ___
- [ ] % del tiempo total: ___%

### 3. Analizar Oportunidades de Cacheo

#### Cach├® de Dependencias

```yaml
# GitLab CI - Verificar configuraci├│n de cach├®
# .gitlab-ci.yml

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/        # Node.js
    - .nuget/              # .NET
    - ~/.m2/               # Maven
    - vendor/              # Composer

# Verificar hit/miss ratio en logs
grep -E "cache|Cache" build.log
```

```bash
# Buscar si cach├® est├í configurada
grep -A5 "cache:" .gitlab-ci.yml

# Verificar tama├▒o de dependencias (candidatas a cachear)
du -sh node_modules/
du -sh ~/.nuget/packages/
```

- [ ] Cach├® de dependencias: Ô£à Configurada / ÔØî Falta
- [ ] Hit ratio estimado: ___%

#### Cach├® de Docker

```dockerfile
# Verificar multi-stage builds
# Dockerfile

# Ô£à Bueno - Cachea dependencias separadamente
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
COPY *.csproj ./
RUN dotnet restore  # Esta capa se cachea si .csproj no cambia
COPY . ./
RUN dotnet publish

# ÔØî Malo - Invalida cach├® siempre
COPY . ./
RUN dotnet restore
RUN dotnet publish
```

- [ ] Multi-stage build: Ô£à / ÔØî
- [ ] Orden de capas optimizado: Ô£à / ÔØî

### 4. Analizar Paralelizaci├│n

```yaml
# GitLab CI - Jobs que pueden ser paralelos
stages:
  - build
  - test        # ┬┐Pueden correr en paralelo?
  - lint        # ┬┐Depende de build?
  - security    # ┬┐Depende de build?

# Verificar dependencias entre jobs
grep -E "needs:|dependencies:" .gitlab-ci.yml
```

**An├ílisis de dependencias:**

| Job | Necesita | Podr├¡a Paralelizar |
|-----|----------|-------------------|
| unit_tests | build | Ô£à Con lint |
| lint | ninguno | Ô£à Con build |
| security_scan | ninguno | Ô£à Con build |
| integration_tests | build, db | ÔØî Secuencial |

- [ ] Jobs paralelos identificados
- [ ] Bottlenecks de secuencialidad

### 5. Optimizar Compilaci├│n

#### .NET

```bash
# Verificar uso de incremental build
grep -E "dotnet build|dotnet publish" .gitlab-ci.yml

# Optimizaciones:
# - Usar dotnet build --no-restore si ya se hizo restore
# - Usar ReadyToRun para publish
# - Reducir n├║mero de proyectos compilados
```

```xml
<!-- Verificar en .csproj -->
<PropertyGroup>
  <PublishReadyToRun>true</PublishReadyToRun>
  <TieredCompilation>true</TieredCompilation>
</PropertyGroup>
```

#### Node.js

```bash
# Verificar uso de npm ci vs npm install
grep -E "npm ci|npm install|yarn" .gitlab-ci.yml

# npm ci es m├ís r├ípido en CI (usa package-lock.json)
```

- [ ] Optimizaciones de compilaci├│n aplicables identificadas

### 6. Analizar Tests

```bash
# Tiempo de tests
# Buscar en logs o configurar reporte de tiempos

# .NET
dotnet test --logger "console;verbosity=detailed" 2>&1 | \
  grep -E "Duration:|Passed|Failed"

# Jest
jest --verbose --testLocationInResults
```

**Optimizaciones de tests:**
- [ ] Tests paralelos habilitados
- [ ] Tests lentos identificados (>1 seg cada uno)
- [ ] Candidatos a mock vs integraci├│n

### 7. Generar Plan de Optimizaci├│n

| Optimizaci├│n | Impacto Estimado | Esfuerzo | Prioridad |
|--------------|------------------|----------|-----------|
| A├▒adir cach├® node_modules | -2 min | Bajo | Alta |
| Paralelizar lint + build | -1 min | Bajo | Alta |
| Optimizar Dockerfile layers | -1.5 min | Medio | Media |
| Reducir tests redundantes | -1 min | Alto | Baja |

- [ ] Plan generado
- [ ] Prioridades asignadas

---

## Output Esperado

```
====== PROC-27 COMPLETADO [TIMESTAMP] ======
Proyecto: [nombre]
CI/CD: GitLab CI / Azure DevOps

M├ëTRICAS ACTUALES:
- Duraci├│n promedio: X min
- P90: Y min
- Objetivo: Z min
- Estado: Ô£à OK / ÔÜá´©Å Lento / ÔØî Cr├¡tico

BREAKDOWN POR STAGE:
| Stage | Tiempo | % Total |
|-------|--------|---------|
| build | 5 min | 40% |
| test | 4 min | 32% |
| docker | 2 min | 16% |

BOTTLENECKS IDENTIFICADOS:
1. Stage 'build': 40% del tiempo, no usa cach├®
2. Tests secuenciales: podr├¡an paralelizarse

CACHEO:
- Dependencias: ÔØî No configurado
- Docker layers: ÔÜá´©Å Sub├│ptimo

PARALELIZACI├ôN:
- Jobs paralelos actuales: X
- Jobs paralelizables: Y adicionales

PLAN DE OPTIMIZACI├ôN:
| Acci├│n | Ahorro | Esfuerzo | Prioridad |
|--------|--------|----------|-----------|
| Configurar cach├® | -2 min | Bajo | 1 |
| Paralelizar jobs | -1 min | Bajo | 2 |

AHORRO TOTAL ESTIMADO: X min (Y%)

ACCIONES INMEDIATAS:
1. [tarea 1]
2. [tarea 2]
```

---

## Criterios de ├ëxito

- [ ] Build time < objetivo (10 min para PR)
- [ ] Cach├® configurado y funcionando
- [ ] M├íxima paralelizaci├│n aprovechada
- [ ] Plan de optimizaci├│n documentado

---

## Alertas y Escalaci├│n

| Severidad | Condici├│n | Acci├│n |
|-----------|-----------|--------|
| CRITICAL | Build > 20 min | Optimizaci├│n urgente |
| WARNING | Build > 15 min | Planificar mejoras |
| INFO | Build < 10 min | Documentar buen estado |

---

## Automatizaci├│n

En ejecuci├│n no-interactiva:
1. Recopilar m├®tricas de ├║ltimos builds
2. Analizar breakdown por etapa
3. Verificar configuraci├│n de cach├®
4. Identificar paralelizaci├│n posible
5. Generar reporte y recomendaciones

---


---

## Output Estructurado (Nexus)

Al finalizar, el agente DEBE generar un bloque JSON con el siguiente formato para que Nexus pueda procesarlo automaticamente:

```json
{
  "result": "success",
  "summary": "Ejecucion de PROC-27 completada. [Descripcion breve de resultados]",
  "metrics": {
    "issues_found": 0,
    "issues_resolved": 0,
    "pipelines_checked": 10, "failures_found": 1,
    "custom": {
      "procedure_specific_metric": "value"
    }
  },
  "backlog_items": [
    {
      "title": "Titulo del item de seguimiento",
      "description": "Descripcion detallada si se requiere accion futura",
      "priority": "medium",
      "type": "improvement",
      "tags": ["proc-27"]
    }
  ],
  "next_steps": [
    "Accion recomendada 1",
    "Accion recomendada 2"
  ],
  "warnings": [
    "Advertencias encontradas durante la ejecucion"
  ]
}
```

**Campos requeridos:**
- `result`: `"success"` | `"partial"` | `"failed"`
- `summary`: Resumen ejecutivo en 1-3 lineas

**Metricas especificas de este procedure:**
- builds_analyzed, avg_time_sec, bottlenecks_found

**Criterios de resultado:**
- `success`: Procedimiento completado sin errores criticos
- `partial`: Completado con algunos problemas menores o items pendientes
- `failed`: Error critico o no se pudo completar

## Historial de Ejecuciones

| Fecha | Proyecto | Antes | Despu├®s | Ahorro | Optimizaciones |
|-------|----------|-------|---------|--------|----------------|
| | | | | | |