CI/CD Agéntico: de Pull Request a Producción sin los Pequeños Inconvenientes

Así que bienvenidos a todos. Hoy, hablaremos sobre la próxima evolución en la entrega de software, que básicamente consiste en mover nuestros pipelines de CI CD de una simple autonomía a una verdadera autonomía. Así que hoy, exploraremos cómo integrar flujos de trabajo agenticos inteligentes en el ciclo de desarrollo para crear procesos que no solo sean más rápidos, sino también fundamentalmente más fluidos e inteligentes, lo que eliminará las fricciones diarias que hemos llegado a aceptar como normales en nuestro desarrollo.

Así que hablemos rápidamente sobre la paradoja, ya que ya no es un concepto novedoso. Hemos estado usando CI CD durante años y años, y es realmente un pilar de los equipos modernos de DevOps y de ingeniería de alto rendimiento. E indudablemente ha acelerado la entrega de software, reducido el tiempo de inactividad y también mejorado la calidad de los productos a través de la automatización. Y hemos construido estos increíbles pipelines que automáticamente construyen, prueban y también despliegan nuestro código.

Sin embargo, hay una paradoja aquí. A pesar del alto grado de automatización, la experiencia diaria para los desarrolladores a menudo está lejos de ser sin fricciones. Así que hemos automatizado con éxito la mayoría de los pasos discretos de los procesos, como la construcción, prueba, ejecución, despliegue y cosas por el estilo. Pero en realidad no hemos automatizado el aspecto de la inteligencia. La parte de la toma de decisiones y la carga cognitiva que realmente conecta estos pasos y esta brecha crea un flujo constante de frustraciones menores pero acumulativas, que llamo muertes por mil pequeños cortes, que básicamente drenan la productividad y la moral de los ingenieros. Así que definamos cuáles son estos pequeños cortes, porque el título de mi charla es sobre pequeños cortes en estos. Así que básicamente son pequeños puntos persistentes de fricción que todos encontramos diariamente como ingenieros y desarrolladores.

Así que, en primer lugar, lo primero y más importante, son las revisiones lentas y subjetivas. Puede que hayas oído hablar de situaciones donde una pull request puede quedarse horas o días esperando a algún revisor humano. Pero cuando la revisión ocurre, el feedback puede ser inconsistente, lo cual en realidad tiene un nombre, que es llamado ruleta del revisor, donde la calidad y el enfoque de la revisión dependen completamente de a quién se le asigna la revisión en lugar de cómo está escrito el código. Correcto. El segundo son los cuellos de botella de seguridad.

Así que hemos hecho un gran trabajo integrando herramientas de seguridad como pruebas de seguridad de aplicaciones estáticas o como lo llamamos, SAST y análisis de composición de software o SCA en nuestros pipelines. Pero al hacerlo, a menudo solo hemos desplazado el problema. Así que en lugar de conocer estas vulnerabilidades desconocidas, ahora solo enfrentamos un retraso de alertas, creando un nuevo problema para nosotros y convirtiendo a los desarrolladores en parches de vulnerabilidades a tiempo completo. Así que esto crea una alerta para Tegan's que ralentiza la característica.

Y el tercero es la depuración compleja. Así que cuando un pipeline falla, no es una solución simple muchas veces. E identificar la causa raíz se convierte en un problema separado por sí mismo. ¿Y es el problema en algún código nuevo que hicimos, o es una prueba que es inestable o un entorno mal configurado o tal vez una dependencia desactualizada?

Así que esta ambigüedad, nuevamente, añade más a nuestro tiempo. Y el cuarto es la prueba ineficiente, que es como cuando escribimos código, a menudo tenemos pipelines que toman un enfoque de fuerza bruta donde ejecutamos un conjunto completo de pruebas de regresión por solo un pequeño cambio menor. Así que como solo una edición de una línea, no debería desencadenar horas y horas de pruebas. Sin embargo, a menudo lo hace, lo cual es un enorme desperdicio de recursos computacionales y, lo más importante, tiempo de los desarrolladores. Correcto.

Y. Para combinar esto, todo esto culmina en una sobrecarga cognitiva. Los desarrolladores se ven obligados a cambiar constantemente de contexto, desde escribir código, perseguir revisiones hasta descifrar una construcción fallida, clasificar una alerta de seguridad. Y este cambio constante es un conocido asesino de la productividad y una fuente importante de agotamiento de los desarrolladores.

Y esto es algo que estamos tratando de abordar con este nuevo desarrollo agentic de CICD. Entonces, ¿cuál es el camino a seguir aquí? Básicamente requerimos un cambio de paradigma. Así que debemos ir más allá de la simple automatización y debemos abrazar la autonomía. Y creo que mi tesis aquí es que podemos eliminar estos pequeños problemas al agregar estos agentes inteligentes directamente en nuestro flujo de trabajo de CICD. Así que el objetivo aquí no es solo construir un pipeline que sea una secuencia de pasos automatizados, sino también un pipeline que sea proactivo, adaptativo y a menudo también auto-reparador.

Un sistema auto-reparador es básicamente un sistema que anticipa problemas, toma decisiones inteligentes y trabaja activamente para resolver los problemas sin intervención humana. Así que en los próximos. Como 15, 20 minutos, también hablaremos sobre cómo lograr esto. Comenzaremos definiendo el paradigma de la agenda y luego recorreremos la anatomía del pipeline potenciado por agentes. Entonces, ¿qué es un flujo de trabajo agéntico?

Primero establezcamos una definición clara. Un flujo de trabajo agéntico se refiere a un sistema impulsado por IA que puede operar autónomamente, adaptarse a condiciones cambiantes y ejecutar tareas inteligentemente sin requerir supervisión humana constante. Esto es diferente de nuestra automatización tradicional como la automatización de procesos robóticos o como lo llamamos RPA, que sigue un conjunto rígido y predefinido de reglas. Los componentes principales de un agente dan esta capacidad avanzada, que obviamente tiene el LLM para entender situaciones complejas, un módulo de planificación para descomponer metas en pasos y la capacidad de usar herramientas como llamar a APIs o ejecutar scripts. Y por supuesto, tenemos la memoria para mantener el contexto de todo lo que está sucediendo.

Así que este cambio no es simplemente una mejora incremental, sino que en realidad representa un cambio fundamental donde se toman las decisiones. Las automatizaciones tradicionales son generalmente decisiones preprogramadas hechas por humanos. Pero en el caso de estos sistemas agénticos, son capaces de tomar sus propias decisiones en tiempo real para lograr un objetivo definido por humanos.

Así que con eso, me gustaría presentar. Ver un CD o más bien lo llamaremos continuous agentic y continuous deployment. Así que estamos pasando de CICD a CCD ahora.

Esto no es simplemente como rociar algunas herramientas impulsadas por IA en nuestros archivos YAML existentes. Es realmente un cambio arquitectónico más profundo. Así que estamos pasando de un pipeline lineal rígido que se asemeja a una línea de ensamblaje.

Imagina como CSCD es una línea de ensamblaje a un sistema colaborativo dinámico que tiene un equipo de boxes de alto rendimiento como en la Fórmula 1. Así que una línea de ensamblaje es, por supuesto, como una secuencia de tareas predefinida. Si una estación falla, toda la línea se detiene y necesitas que un humano intervenga y reanude el proceso.

Pero, por otro lado, un equipo de boxes es un equipo de especialistas con un objetivo compartido. Se comunican y adaptan en tiempo real a lo que la situación demande, que es el modelo mental para un pipeline agéntico, un sistema dinámico y autooptimizante donde agentes inteligentes colaboran para llevar el código a producción de manera más segura y rápida. Así que este es un nuevo equipo de pipeline, al que llamo el equipo de boxes de IA.

Así que tenemos todos estos agentes aquí. Tenemos el agente revisor de código, el agente analista de seguridad, el agente estratega de pruebas, el coordinador de lanzamientos y el agente orquestador. Así que probablemente estos agentes no necesiten explicación.

Hacen lo que su nombre sugiere. Y todos ellos operan de manera colaborativa en un solo en una forma cohesiva para lograr este flujo de trabajo CACD completamente autónomo. Así que esta es la evolución de estos flujos de trabajo, diría yo. Este es un CIC tradicional, CIC con herramientas de IA. Y finalmente, CIC, como definimos ahora mismo. Tenemos estas decisiones tradicionales basadas en reglas en un archivo YAML en un flujo regular. Y tenemos retroalimentación reactiva, que nos proporciona como fallos de estado de construcción y cosas así.

La columna del medio es lo que estamos usando ahora mismo. Tenemos herramientas como GitHub Copilot, que proporciona sugerencias, pero aún tienes que tener un humano que debe interpretar el resultado y tomar la decisión final. Y esto sigue siendo en gran medida lineal porque el desarrollador actúa como un colaborador junto con la IA. Pero estamos pensando más allá de eso, que es nuestro flujo de trabajo CICD o CICD de agentes, que es la parte final a la que queremos llegar, donde la toma de decisiones es autónoma y delegada a agentes. Y la retroalimentación es más proactiva con agentes no solo sugiriendo, sino también actuando sobre los cambios como la refactorización automática de código y la seguridad moviéndose de simples alertas a remediación automática. Así que esto es de lo que estoy hablando, la evolución aquí.

Y luego también tenemos el orquestador final, que, como su nombre sugiere, es un orquestador que supervisa a todos estos agentes y se asegura de que la entrega final sea como se espera. Así que esta es la anatomía de un pipeline de agentes. Así es como se vería el viaje de una pull request. Así que así es como vamos a seguir cada paso aquí. Vamos a seguir el viaje de esta pull request a través de este pipeline y ver cómo nuestro equipo de boxes de IA colabora en cada etapa usando herramientas del mundo real que existen. Así que tenemos estas cuatro etapas que he definido.

Ahora, veamos la primera etapa, que es el programador de API o revisión de código. Y es posible que hayas usado muchas de estas herramientas. Una de ellas es GitHub, GitHub Co-Pilot Code Review. Y así, en el momento en que un desarrollador abre una pull request, el primer agente se pone a trabajar, que es el agente revisor de código. Está representado por herramientas como co-pilot code review y comienza inmediatamente su análisis. Aborda directamente el problema de revisión subjetiva lenta donde no tienes que esperar a que un ingeniero revise tu código.

Simplemente tienes este revisor que comienza inmediatamente tan pronto como abres una solicitud. Y no es solo un linter. Verifica muchas cosas más profundas que un humano haría porque es un revisor potenciado por LLM y puede entender la intención del código. Puede verificar fallos lógicos, problemas de rendimiento o violaciones de términos complejos, patrones arquitectónicos específicos que están definidos en el código. Así que, por ejemplo, puedes crear una instrucción personalizada en tu repositorio que diga que el servidor nunca debe hacer una llamada directa a la base de datos.

Siempre debe pasar por la API del servicio de gestión de usuarios y el LLM realmente entendería eso. Y verá si estás haciendo cambios similares o haciendo llamadas directas a la API de la base de datos y te dará retroalimentación accionable, no solo advertencias crípticas, sino que realmente activará y te dará comentarios y también te dará y como también potencialmente te dará como un primer pase, pero tal vez solucionará ese problema por ti. Y básicamente esa es la primera etapa. La segunda etapa es usar análisis de seguridad autónomo, que es a través de herramientas como Semgraph Assistant. Esto complementa herramientas como CodeQL, que también proporciona sus propias correcciones generadas por IA, pero también introduce dos capacidades agenticas más avanzadas.

En primer lugar, es el triaje inteligente. Utiliza un modelo de IA para analizar realmente los hallazgos y predecir cuáles de ellos van a ser falsos positivos y filtrarlos automáticamente según la perspectiva del desarrollador. Y esto ataca directamente el problema que estamos mencionando, que es la alerta por ruido, asegurando que los desarrolladores realmente dediquen tiempo a problemas reales.

Y en segundo lugar, que quizás es la característica más impresionante, es que presenta aprendizaje organizacional a través de una función que tiene, que se llama memorias. Así que cuando un desarrollador clasifica un hallazgo o personaliza una solución sugerida, puede proporcionar retroalimentación al agente y el agente recuerda esta preferencia y la aplica para futuras sugerencias. Así que, por ejemplo, si tu organización prefiere una biblioteca interna específica para sanitizar entradas en lugar de otra cosa, el agente, puedes hacerle saber al agente que esta es una preferencia y lo incorporará en el conocimiento y en su consejo de remediación en el futuro, lo cual es una característica clave de un agente avanzado, ¿verdad?

Que es la capacidad de aprender y adaptarse basado en la retroalimentación del entorno. Y ahora la etapa tres, que es el estratega de pruebas inteligente, donde una vez que el código ha sido revisado y ahora es seguro, no hay fallos de seguridad, se mueve a la primera etapa, que es la etapa de pruebas, donde el agente intenta resolver este problema de pruebas ineficientes. Así que en lugar de ejecutar cada prueba en el conjunto, el agente utiliza la selección predictiva de pruebas. El agente analizará los cambios en el código que fueron creados y entenderá el gráfico de dependencias del código y consultará las ejecuciones de pruebas históricas.

Y basado en este contexto, seleccionará y priorizará el subconjunto más relevante de pruebas que tienen más probabilidades de detectar una regresión del cambio específico. Así que básicamente, para darte un ejemplo, una empresa de videojuegos implementó un agente que omite inteligentemente pruebas innecesarias después de un pequeño ajuste. Y esto realmente les ayudó a reducir su tiempo total de pruebas en un 30 por ciento sin ninguna pérdida en la cobertura efectiva de pruebas. Así que este agente actúa como un optimizador crítico de recursos, que ahorra valioso tiempo de cómputo y también reduce el ciclo de retroalimentación para los desarrolladores.

Así que todas estas herramientas son agentes especializados, pero su verdadero potencial solo se realiza cuando se orquestan como un equipo cohesivo, lo que nos lleva a nuestra etapa final, que es orquestar como construir el equipo a través de un agente orquestador. Así que estos agentes individuales son poderosos, pero no colaboran juntos. Así que cambiamos sus acciones a través de un marco de orquestación de agentes, que puedes llamarlo como un sistema nervioso central de todo este conjunto. Y hay múltiples herramientas para eso. Así que, por ejemplo, este es Landgraf, que es de código abierto.

Y hay otro, que es Autogen de Microsoft. Así que Landgraf realmente utiliza un enfoque basado en gráficos donde tiene una secuencia de flujos condicionales y un borde condicional, que básicamente verifica las salidas de los agentes, como, por ejemplo, si comenzará con el agente de revisión de código, verificará la salida. Si encontró problemas críticos, pasará al siguiente. Y básicamente actúa como un flujo. Actúa en un flujo singular. Y si todas las verificaciones pasan eventualmente, entonces el flujo de trabajo se mueve a un nodo final de aprobación humana donde todo el proceso se detiene, publica un resumen para el humano y espera a que el mantenedor dé la señal final de aprobación. Y solo después de eso, el gráfico procede al estado final donde activará la fusión.

fusión. Este es un enfoque que básicamente proporciona el control y la fiabilidad necesarios para los sistemas de producción, abordando directamente las preocupaciones de confianza y seguridad que son inherentes en el sistema autónomo, que es básicamente el nodo final de aprobación humana. Una forma diferente de ver esto es el marco Autogen.

Así que mientras Landgraf utiliza un diagrama de flujo estructurado, Autogen es más como una conversación dinámica donde defines un conjunto de agentes con diferentes roles y colaboran hablando realmente entre ellos, donde es como imaginar un chat grupal gestionado. El flujo de la conversación no está rígidamente predefinido como lo estaba antes. Surge basado en el diálogo entre los agentes.

Así que este enfoque sobresale en problemas complejos y abiertos que requieren una lluvia de ideas creativa o un diagnóstico de múltiples pasos. Así que básicamente tienes todos estos agentes que si uno surge con un problema, entonces lo comunicará a los demás y las cosas son dinámicas. No es como un flujo fijo como vimos antes que.

Esto es, todos estos agentes están trabajando juntos y proponiendo soluciones hasta que se encuentran las causas raíz, como puedes ver en el diagrama de flujo aquí. Así que hemos construido un pipeline CI CD altamente autónomo, pero esto naturalmente plantea la cuestión de la confianza, las puertas de fusión tradicionales, que son la cobertura de pruebas y umbrales, verificaciones de enlaces, escaneos de vulnerabilidades. Estos son vitales, pero son primitivos. Tratan cada cambio como el mismo, reduciendo el juicio complejo a binario. Así que este resultado es tanto ineficiente como tiene riesgos de cambios de bajo impacto, como cambios de bajo impacto pueden ser bloqueados por ruido no relacionado, mientras que cambios críticos pueden pasar sin suficiente escrutinio. Así que con eso, introducimos un guardián de calidad final, que es un agente inteligente que actúa como el árbitro final de. Árbitro de la preparación para la fusión. Así que agrega todas estas señales a lo largo de todo el pipeline, que es como complejidad del código, cobertura de pruebas, Delta's de seguridad, confianza fija, sentimientos de revisión, impactos de rendimiento, cosas así. Y el agente no solo te da una respuesta, si es un aprobado o un rechazo, te da una puntuación de confianza más alta, que es como un número. Y te dará una explicación de que. Baja complejidad, alta cobertura de pruebas, una vulnerabilidad mediada media con como sin agresiones de rendimiento. Y luego este curso impulsa la estrategia de humano en el bucle. Las fusiones de alta confianza pueden proceder automáticamente. Las ambiguas se presentan a los humanos para su aprobación, y las arriesgadas son bloqueadas con informes detallados. Y esto crea un sistema confiable que escala con juicios humanos. Y mantiene a los ingenieros enfocados donde son más necesarios y eleva las puertas de fusión de reglas estáticas a activos inteligentes dinámicos.

Así que recapitulemos rápidamente nuestro viaje. Comenzamos identificando estos problemas menores y luego vimos cómo un enfoque agéntico puede sanar estos problemas proporcionando revisiones inteligentes instantáneas, proporcionando remediación automática de problemas de seguridad e implementando estrategias de prueba eficientes y adaptativas. Luego vimos nuestro equipo de boxes de IA, que eran los agentes especializados. Y luego también aprendimos cómo organizar estos agentes usando un marco de orquestación como line graph y auto gen. Y finalmente, diseñamos un guardián inteligente impulsado por IA para asegurar que este pipeline permanezca seguro, confiable, confiable, y también bajo supervisión humana, que es el resultado final aquí es un proceso de desarrollo que se siente menos como una serie de obstáculos frustrantes, o diría problemas menores, y más como un estado de superfluidez. Así que este es un cambio tecnológico que inevitablemente transformará nuestros roles como desarrolladores. Y la buena noticia es que mientras automatiza la mayoría de las partes tediosas y frustrantes, pasaremos menos tiempo solucionando estas vulnerabilidades, descifrando registros de construcción, registros de construcción, o esperando revisiones, y que realmente nos libera para centrarnos en. Cosas que realmente importan, que es el diseño de sistemas de alto nivel, abordando desafíos arquitectónicos novedosos, y comprendiendo profundamente los problemas de negocio que estamos tratando de resolver.

Y por supuesto, con esto, el rol del desarrollador va a evolucionar. Pasaremos de ser programadores primarios a convertirnos en diseñadores y orquestadores de sistemas inteligentes de IA. Y creo que la habilidad de ingeniería más invaluable en este paradigma será la capacidad de diseñar, guiar y supervisar los sistemas agénticos. Y como podría decir un experto, el prompting es la nueva depuración. Y no se trata de reemplazo, sino de elevación de roles como desarrollador. Entonces, ¿cuál es la visión a largo plazo aquí? Así que el próximo horizonte es un pipeline que no solo está poblado por agentes en sí mismo, sino que es un agente en sí mismo. Así que imagina un sistema que pueda monitorear sus propios métricas de rendimiento, tiempo de entrega para cambios, tasa de fallos de cambio, tiempo medio de recuperación, y usar todos estos datos para reconfigurar sus propios flujos de trabajo. Así que podría aprender que cierta clase de cambios rara vez se beneficia de un escaneo de seguridad completo y dinámico, y ajustará dinámicamente sus propias reglas. Será capaz de experimentar con diferentes estrategias para encontrar el equilibrio óptimo de velocidad y cobertura. Y básicamente esto logrará el objetivo final de que el pipeline se convierta en una entidad adaptativa y auto-aprendizaje que también es una entidad auto-sanadora, que es el objetivo final del CI CD agéntico, que es esencialmente un ecosistema de desarrollo que mejorará autónoma y continuamente su propia eficiencia, fiabilidad, calidad, y permitiendo a los ingenieros humanos centrarse en cosas completamente nuevas y un nuevo conjunto de habilidades.