¿Cuántas pestañas tienes abiertas junto a la pull request?
Imagina que estás abordando una nueva incidencia en el flujo de onboarding de la prueba gratuita de tu producto: hacer opcional el paso «invite your teammates». A medida que aumentan los registros, el equipo de soporte sigue señalando este paso como un punto de fricción. Una mejora rápida, ¿verdad?
Desde la definición del alcance hasta el despliegue, necesitas responder estas cuatro preguntas:
¿Es realmente el cambio correcto?
¿Están en orden las dependencias que estoy modificando?
¿Cómo puedo lanzarlo de forma segura?
¿Es seguro realizar el despliegue ahora mismo?
Cada respuesta se encuentra en una herramienta diferente, por lo que trabajar en la pull request implica trasladar el mismo contexto entre cuatro lugares distintos.
Las aplicaciones de agentes de GitHub llevan las herramientas que necesitas para responder estas preguntas directamente al lugar donde ya trabajas, utilizando la misma plataforma y el mismo entorno de ejecución que nuestro propio agente de Copilot en la nube.
El siguiente ejemplo muestra cómo puedes usar servicios de los que ya dependes, como Amplitude, Endor Labs, LaunchDarkly y PagerDuty, para responder estas preguntas y completar esta solicitud sin salir de GitHub.
1. Antes de comenzar el desarrollo
El equipo de soporte afirma que el paso «invite your teammates» resulta molesto para los clientes que están realizando el onboarding de tu producto, pero no ha proporcionado información sobre quiénes se han quejado ni sobre si esas quejas han provocado la pérdida de clientes. Es razonable que seas escéptico. Por eso, en lugar de abrir Amplitude y crear una consulta para validar tu hipótesis, preguntas directamente al agente de Amplitude desde la pestaña Agents:
@amplitude[agent] ¿La finalización del paso de invitación al equipo está relacionada con el éxito en las etapas posteriores del funnel? Desglósalo según los segmentos que medimos.
La distinción es clara: los usuarios de equipo que completan el paso tienen más probabilidades de ser retenidos posteriormente, mientras que no existe una relación similar en el caso de los usuarios individuales. Ahora hay motivos para volver a definir el alcance: retrasa este paso para quienes se registran como usuarios individuales y mantenlo para los equipos.
El acceso a las perspectivas del producto está ahora dentro de GitHub, lo que permite corregir el rumbo antes de escribir código.
2. Durante el desarrollo
Copilot abre un pull request preliminar para el cambio. La aplicación también actualiza las dependencias utilizadas en el flujo de onboarding. En lugar de esperar a que un análisis de CI falle más adelante, preguntas al agente de Endor Labs en el comentario:
@endor-labs-github-agenthq[agent] ¿Hay algo que deba tener en cuenta en las dependencias afectadas por este pull request?
El agente identifica las dependencias modificadas, las comprueba en busca de vulnerabilidades de seguridad conocidas y de riesgos más amplios relacionados con los paquetes, y después presenta un informe en el pull request. Esta vez, todo parece estar limpio. No hay nada que deba corregirse.
La revisión de dependencias se convierte en un control proactivo mientras el cambio todavía está delante de ti. Es mucho mejor que corregirlo después de que falle un análisis de CI.
3. Puesta en producción
El hallazgo anterior ya se está trasladando a la aplicación: los usuarios individuales que se registran utilizan la ruta opcional, mientras que los equipos mantienen la ruta actual. Como estos segmentos se determinan durante el registro, un feature flag puede dirigirse directamente a ellos. Pídele al agente de LaunchDarkly que lo configure por ti, como se lo pedirías a un compañero de equipo:
@launchdarkly-agent[agent] crea un feature flag para este pull request y conéctalo al código, por favor.
- key: defer-team-invite
- type: boolean
- default: false
- target: solo-intent signups
- rollout: internal > 5% > 25% > 100%
El agente crea el feature flag en LaunchDarkly y añade la implementación en el código como un commit para que la revises. Si el entorno objetivo requiere aprobación, crea una solicitud de aprobación en lugar de aplicar directamente el cambio de segmentación. Una persona seguirá decidiendo si la puesta en producción debe continuar.
La configuración del flag deja de ser un proceso que requiere una segunda herramienta, una transferencia manual de código y coordinación en Slack, y se convierte en un único comentario en el pull request y un commit para que lo revises.
4. Antes de la puesta en producción
La revisión indica que el código es correcto; sin embargo, si el servicio está en buenas condiciones para una implementación es una cuestión diferente.