Asignar las responsabilidades de los agentes al SDLC
En esta unidad, aprenderá lo siguiente:
- Por qué el mapeo de responsabilidades del agente a las fases del ciclo de vida del desarrollo de software mejora la fiabilidad
- Cómo se mapean las etapas del ciclo de vida del desarrollo de software (SDLC) a los artefactos y superficies de control de GitHub.
- Definir límites arquitectónicos para el comportamiento del agente para reducir el riesgo y mejorar la auditoría
¿Por qué importa la asignación de responsabilidades?
Los sistemas de agentes no deberían operar en todo el SDLC sin restricciones. Cuando un agente se trata como un desarrollador de uso general, resulta difícil razonar sobre su comportamiento, limitar su impacto o los resultados de auditoría.
Un enfoque más confiable consiste en asignar el agente a fases de ciclo de vida específicas en las que GitHub pueden aplicar límites. La mayoría de los equipos comienzan por determinar el ámbito de los agentes en las fases de implementación y validación, donde las solicitudes de incorporación de cambios y los flujos de trabajo proporcionan puntos de control naturales.
Asignación de fases de SDLC a artefactos de GitHub
El SDLC se puede simplificar en el planeamiento, la implementación, la validación y el despliegue. Cada fase se asigna a una "plataforma" diferente de GitHub donde se pueden registrar el trabajo y la evidencia.
| La fase de SDLC | Responsabilidad típica del agente en GitHub | Artefacto principal |
|---|---|---|
| Planificación | Borrador de ámbito, pasos de plan, definición de criterios de éxito | Problemas de GitHub, descripciones o comentarios de los pull requests, pestaña Agentes |
| Implementation | Crear rama, realizar cambios, abrir o actualizar pr | Rama, confirmaciones, solicitud de incorporación de cambios |
| Validación | Ejecución de comprobaciones, adjuntar artefactos, iterar en caso de errores | Ejecuciones de flujo de trabajo, comprobaciones, artefactos |
| Deployment | Normalmente restringido; requerir aprobaciones para acciones confidenciales | Entornos e aprobaciones de implementación |
Definir límites arquitectónicos para el comportamiento del agente para reducir el riesgo y mejorar la auditoría
- Defina el alcance previamente para reducir el radio de afectación: limite los directorios que un agente puede modificar mediante directiva y control.
- Trate los cambios de flujo de trabajo e infraestructura como mayor riesgo que los cambios en el código de la aplicación.
- Preferir el trabajo basado en PR incluso para la automatización; evite los cambios directos a la rama predeterminada.
Un límite de diseño común es: los agentes proponen; humanos y la política aceptan. El agente puede preparar el trabajo y enviarlo a través de una solicitud de incorporación de cambios, pero la política del repositorio y los revisores humanos deciden si ese trabajo se fusiona o implementa.
Ejemplo práctico en GitHub
Un agente de remediación de dependencias está destinado a la implementación:
- El agente detecta una dependencia vulnerable (por ejemplo, desde una alerta de seguridad o un problema).
- El agente crea una rama.
- El agente actualiza la dependencia y el archivo de bloqueo.
- El agente abre un pull request que incluye un plan estructurado y las señales esperadas de éxito.
En ese momento, la responsabilidad delimitada del agente se puede considerar completa. La validación y la aceptación se realizan mediante comprobaciones, revisiones y controles de directiva.