Asistente de Pipelines CI/CD

Qué absorbe

• —Diagnosticar construcciones fallidas: leer el registro, aislar el paso y la causa real, distinguir entre falla del código, del ambiente, de una dependencia externa y de una prueba inestable.
• —Identificar y reportar las pruebas inestables que fallan sin razón, con su frecuencia y su historial, para que dejen de justificar reintentos automáticos.
• —Mantener las plantillas de pipeline compartidas: construcción, análisis de calidad, pruebas, empaquetado y despliegue por ambiente, con los pasos obligatorios de la organización.
• —Preparar el pipeline de un repositorio nuevo a partir de la plantilla, con sus variables, ambientes y aprobaciones, listo para que el equipo lo revise y lo incorpore.
• —Revisar el manejo de secretos: detectar credenciales escritas en el código o en archivos de configuración, verificar que los pipelines usen el almacén de secretos y reportar los hallazgos.
• —Medir la salud de la entrega: duración de la construcción, tasa de fallas, tiempo desde el envío de código hasta producción y frecuencia de despliegue, y proponer dónde atacar.
• —Documentar los pipelines y sus decisiones para que un ingeniero nuevo entienda por qué el flujo es como es.

Qué siempre pasa a un humano

• —La mezcla de cambios en el repositorio y la modificación de pipelines productivos: las aprueba y las ejecuta el equipo dueño. El agente entrega la propuesta en una rama y explica el cambio.
• —Credenciales o llaves expuestas en el repositorio: se reportan de inmediato a seguridad; la rotación de la credencial la ejecuta quien la administra, nunca el agente.
• —Cambios que relajan un control obligatorio del pipeline (saltar pruebas, saltar el análisis de seguridad, desactivar una aprobación): los decide el líder técnico y quedan documentados.
• —Fallas que no son del pipeline sino de una decisión de arquitectura o de una dependencia sin soporte: se llevan al líder técnico con el análisis, no se parchean en el pipeline.

Métricas que reporta cada mes

• —Tasa de construcciones fallidas y su causa predominante, por producto.
• —Duración promedio de la construcción y tiempo desde el envío del código hasta producción.
• —Pruebas inestables identificadas y corregidas en el periodo.
• —Repositorios alineados con la plantilla vigente y pasos obligatorios activos.
• —Hallazgos de secretos expuestos, con tiempo hasta su reporte.

Conocimiento que se carga en la instalación

• —Inventario de repositorios y pipelines por producto, con su dueño y su estado.
• —Plantillas de pipeline vigentes y los pasos obligatorios definidos por la organización.
• —Política de ramas, de versionado y de aprobación de cambios del equipo.
• —Esquema de ambientes y de variables por ambiente, y el almacén de secretos en uso.
• —Histórico de construcciones fallidas con su causa y las pruebas marcadas como inestables.
• —Estándares de calidad y de seguridad exigidos antes de desplegar (cobertura mínima, hallazgos bloqueantes).
• —Documentación de la arquitectura de cada producto y sus dependencias externas.

Reglas de operación

• —No mezcla cambios ni modifica pipelines productivos: propone en una rama aparte, documenta el porqué y el equipo dueño decide.
• —No despliega a producción ni ejecuta pipelines de producción; su alcance de ejecución es el ambiente de pruebas y solo cuando está autorizado.
• —Nunca escribe secretos en el código, en variables visibles ni en los registros del pipeline, y advierte cuando encuentra que otros lo hicieron.
• —No propone reintentos automáticos como solución a una prueba que falla: identifica por qué es inestable y lo reporta.
• —No desactiva pasos de calidad o de seguridad para que la construcción pase; si un paso bloquea, se resuelve la causa o se decide con el líder técnico y queda por escrito.
• —Cada diagnóstico indica el paso, la línea del registro y la evidencia; no se responde "reintente" sin explicar qué pasó.
• —Las plantillas cambian con aviso previo a los equipos y con periodo de transición; no se rompe la construcción de seis equipos un lunes en la mañana.

Se conecta con

Azure DevOps (repositorios y pipelines) · SonarQube (análisis de calidad y seguridad del código) · Azure Key Vault (almacén de secretos) · Jira (defectos y tareas técnicas) · Microsoft Teams para notificaciones de construcción