Flujos de agentes
Los flujos de GitLab Duo automatizan el DevSecOps posterior al código de wovain, con PostHog detectando y verificando.
Después de fusionar el código, los flujos de agentes de GitLab Duo se encargan del trabajo que lo rodea:
| Flujo | Disparador | Resultado |
|---|---|---|
| Autorreparación | Un error de producción en los registros del servidor, o una excepción del navegador que agrupa el seguimiento de errores de PostHog | Una merge request con la corrección y una prueba de regresión, verificada en producción |
| Explorador | Una programación diaria, o una alerta de KPI de PostHog, leyendo KPI e interfaz | Incidencias con evidencia sobre las mejoras que merecen la pena |
| Desarrollo | Una incidencia que acepta una persona de confianza | Una merge request que lleva la incidencia hasta su cierre |
| Vulnerabilidad corregida | Un nuevo hallazgo SAST alto o crítico | Un parche revisado |
La inyección de fallos mediante feature flags permite demostrar la autorreparación de extremo a extremo: un flag introduce un fallo controlado en producción, el error se registra y el flujo abre la corrección.
El ciclo con PostHog
PostHog detecta, Duo actúa, PostHog verifica:
- Detectar. PostHog observa las visitas reales: excepciones del navegador, el embudo de los comerciantes, clics de rabia y clics muertos, Web Vitals, valoraciones de las ejecuciones y el coste de cada llamada a Nemotron. Cada KPI tiene una alerta que salta mientras no alcanza su objetivo.
- Avisar. Una incidencia del seguimiento de errores o una alerta de KPI activa inicia el pipeline de ops en GitLab. Nada del evento de PostHog llega a GitLab: el job de ops vuelve a leer PostHog por su cuenta.
- Actuar. Un error del navegador se convierte en una incidencia de reparación para el flujo de autorreparación. Las alertas de KPI inician el explorador, como mucho una vez al día; una persona de confianza pasa su mejor propuesta al flujo de Desarrollo. Los cambios de interfaz salen como experimentos de PostHog.
- Verificar. Tras el despliegue, el job de ops vuelve a consultar PostHog: no hay más excepciones de ese error, o la alerta del KPI dejó de saltar. Entonces la incidencia y su incidente se cierran.
Las nueve etapas de DevSecOps
| Etapa | Qué la cubre |
|---|---|
| Plan | El archivo de KPI, las alertas de KPI de PostHog y las incidencias ordenadas del explorador; las incidencias aceptadas para el flujo de Desarrollo |
| Create | Los flujos de Desarrollo y de autorreparación, Vulnerability Resolution, Duo Code Review |
| Verify | Lint, tipos, pruebas, y la comprobación de que la prueba de la corrección falla antes y pasa después |
| Package | La imagen web construida y publicada con cada cambio fusionado |
| Secure | SAST, Secret Detection, análisis de dependencias y de contenedores; vulnerabilidades corregidas por Duo |
| Release | Fusión automática, despliegue en Cloud Run, feature flags de GitLab para la inyección de fallos, experimentos de PostHog |
| Configure | Disparadores, programaciones y etiquetas de Duo en Pulumi; alertas, destinos y panel de PostHog en OpenTofu |
| Monitor | Cloud Logging, seguimiento de errores, alertas de KPI, Web Vitals y analítica de LLM de PostHog, incidentes, la página de estado |
| Govern | Personas de confianza, límites, salvaguardas de la fusión automática, listas de herramientas permitidas y un registro de auditoría |
Detalles
Las definiciones completas, los prompts, los disparadores y las salvaguardas
de cada flujo están en docs/flows.md del repositorio. Esta página es un
resumen y enlazará a ese contenido cuando se publique.