Correlacionar as responsabilidades dos agentes com o SDLC
Nesta unidade, você aprenderá:
- Por que mapear as responsabilidades do agente para os estágios do SDLC melhora a confiabilidade
- Como as etapas do SDLC se correspondem aos artefatos e interfaces de controle do GitHub
- Definir limites arquitetônicos para o comportamento do agente para reduzir o risco e melhorar a auditabilidade
Por que o mapeamento de responsabilidades importa
Os sistemas de agente não devem operar em todo o Ciclo de Vida de Desenvolvimento de Software (SDLC) sem restrições. Quando um agente é tratado como um desenvolvedor de uso geral, torna-se difícil argumentar sobre seu comportamento, limitar seu impacto ou resultados de auditoria.
Uma abordagem mais confiável é mapear o agente para estágios específicos do ciclo de vida em que GitHub pode impor limites. A maioria das equipes começa definindo os agentes para os estágios de implementação e validação, onde pull requests e fluxos de trabalho fornecem pontos de controle naturais.
Mapeando os estágios do SDLC para artefatos do GitHub
O SDLC pode ser simplificado no planejamento, implementação, validação e implantação. Cada estágio é mapeado para uma interface diferente do GitHub, onde o trabalho e as evidências podem ser registrados.
| Estágio do Ciclo de Vida do Desenvolvimento de Software (SDLC) | Responsabilidade típica de agentes no GitHub | Artefato primário |
|---|---|---|
| Planejamento | Escopo do rascunho, etapas do plano, definir critérios de êxito | Issues do GitHub, descrições/comentários de pull requests, guia Agentes |
| Implementation | Criar ramificação, fazer alterações, abrir/atualizar PR | Ramificação, commits, solicitações de pull |
| Validação | Executar verificações, anexar artefatos, revisar quando ocorrerem falhas | Execuções de fluxo de trabalho, verificações, artefatos |
| Implantação | Geralmente restrito; exigir aprovações para ações confidenciais | Ambientes e aprovações de implantação |
Definir limites arquitetônicos para o comportamento do agente para reduzir o risco e melhorar a auditabilidade
- Defina o escopo desde o início para reduzir o impacto: limite os diretórios que um agente pode modificar por meio de políticas e direitos de propriedade.
- Trate as alterações de fluxo de trabalho e infra como um risco maior do que as alterações do código do aplicativo.
- Dê preferência ao trabalho baseado em PRs, mesmo para automação; evite alterações feitas diretamente na ramificação padrão.
Um limite de design comum é: os agentes propõem; humanos e políticas aceitam. O agente pode preparar o trabalho e enviá-lo por meio de uma solicitação de pull, mas são as políticas do repositório e os revisores humanos que decidem se esse trabalho será incorporado ou implementado.
Exemplo prático no GitHub
Um agente de correção de dependência tem como escopo a implementação:
- O agente detecta 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 arquivo de bloqueio.
- O agente abre uma solicitação de pull que inclui um plano estruturado e sinais de sucesso esperados.
Nesse ponto, a responsabilidade definida para o agente pode ser considerada concluída. A validação e a aceitação ocorrem por meio de verificações, revisões e controles de política.