Responsabilidades de agente cartográfico para o SDLC
Nesta unidade, irá aprender:
- Porque é que mapear as responsabilidades dos agentes para os estágios SDLC melhora a fiabilidade
- Como os estágios do SDLC são mapeados para artefatos e superfícies de controlo do GitHub
- Definir limites arquitetónicos para o comportamento dos agentes, de modo a reduzir riscos e melhorar a auditabilidade
Por que o mapeamento de responsabilidades é importante
Os sistemas de agentes não devem operar em todo o SDLC sem restrições. Quando um agente é tratado como um desenvolvedor de propósito geral, torna-se difícil raciocinar sobre o seu comportamento, limitar o seu impacto ou auditar os resultados.
Uma abordagem mais fiável é mapear o agente para estágios específicos do ciclo de vida onde o GitHub pode impor limites. A maioria das equipas começa por definir os agentes para as fases de implementação e validação, onde os pull requests e fluxos de trabalho fornecem pontos de controlo naturais.
Mapear estágios SDLC para artefactos do GitHub
O SDLC pode ser simplificado em planeamento, implementação, validação e desdobramento. Cada estágio mapeia para uma "superfície" diferente do GitHub onde o trabalho e as provas podem ser registados.
| Fase SDLC | Responsabilidade típica de agente em GitHub | Artefacto primário |
|---|---|---|
| Planeamento | Elaborar o âmbito, planear os passos, definir critérios de sucesso | Problemas no GitHub, descrições/comentários de pull requests, separador Agentes |
| Implementation | Criar filial, fazer alterações, abrir/atualizar PR | Ramificação, commits, pedido de pull |
| Validação | Executar verificações, anexar artefatos, repetir em caso de falhas | Execuções de fluxo de trabalho, verificações, artefactos |
| Implantação | Normalmente restritos; exigir aprovações para ações sensíveis | Ambientes e aprovações de implementação |
Definir limites arquitetónicos para o comportamento dos agentes, de modo a reduzir riscos e melhorar a auditabilidade
- Defina o âmbito cedo para reduzir o raio de explosão: limite quais diretórios um agente pode modificar através de política e propriedade.
- Trate o fluxo de trabalho e as alterações de infraestrutura como um risco maior do que as alterações no código da aplicação.
- Prefiro trabalho baseado em relações públicas, mesmo para automação; Evite alterações diretas para o branch padrão.
Um limite comum de design é: agentes propõem; Humanos e políticas aceitam. O agente pode preparar o trabalho e submetê-lo através de um pull request, mas a política do repositório e os revisores humanos decidem se esse trabalho é fundido ou implementado.
Exemplo prático no GitHub
Um agente de remediação de dependências está destinado à implementação:
- O agente deteta uma dependência vulnerável (por exemplo, de um alerta de segurança ou de um problema).
- O agente cria uma ramificação.
- O agente atualiza a dependência e o ficheiro de bloqueio.
- O agente abre um pull request que inclui um plano estruturado e sinais de sucesso esperado.
Nesse momento, a responsabilidade definida pelo agente pode ser considerada completa. A validação e aceitação acontecem através de verificações, revisões e controlos de políticas.