Eseguire il mapping delle responsabilità dell'agente a SDLC
In questa unità si apprenderà quanto segue:
- Perché la mappatura delle responsabilità dell'agente alle fasi del ciclo di vita del software migliora l'affidabilità
- Come le fasi dell'SDLC si collegano agli artefatti di GitHub e agli elementi di controllo
- Definire i limiti dell'architettura per il comportamento dell'agente per ridurre i rischi e migliorare la controllabilità
Perché il mapping delle responsabilità è importante
I sistemi degli agenti non devono operare nell'intero SDLC senza restrizioni. Quando un agente viene considerato come uno sviluppatore generico, diventa difficile ragionare sul comportamento, limitarne l'impatto o i risultati di controllo.
Un approccio più affidabile consiste nell'eseguire il mapping dell'agente a fasi specifiche del ciclo di vita in cui GitHub può applicare limiti. La maggior parte dei team inizia limitando gli agenti alle fasi di implementazione e convalida, in cui pull request e flussi di lavoro forniscono naturali punti di controllo.
Mappatura delle fasi SDLC agli artefatti GitHub
SdlC può essere semplificato in pianificazione, implementazione, convalida e distribuzione. Ogni fase corrisponde a una diversa "superficie" su GitHub in cui è possibile registrare il lavoro e la documentazione.
| Fase SDLC | Responsabilità tipica dell'agente in GitHub | Artefatto primario |
|---|---|---|
| Pianificazione | Bozza di ambito, passaggi di piano, definizione dei criteri di esito positivo | GitHub Problemi, descrizioni/commenti delle richieste pull, scheda Agenti |
| Implementation | Creare un ramo, apportare modifiche, aprire/aggiornare la richiesta pull | Ramo, commit, richiesta pull |
| Convalida | Eseguire controlli, allegare artefatti, iterare sugli errori | Esecuzioni del flusso di lavoro, controlli, artefatti |
| Deployment | Di solito limitato; richiedere le approvazioni per le azioni sensibili | Ambienti e approvazioni della distribuzione |
Definire i limiti dell'architettura per il comportamento dell'agente per ridurre i rischi e migliorare la controllabilità
- Ambito iniziale per ridurre il raggio di esplosione: limitare le directory che un agente può modificare in base a criteri e proprietà.
- Considerare il flusso di lavoro e le modifiche infra come un rischio maggiore rispetto alle modifiche apportate al codice dell'applicazione.
- Preferire il lavoro basato su richieste pull anche per l'automazione; evitare modifiche direct-to-default-branch.
Un limite di progettazione comune è: gli agenti propongono; gli umani e le politiche accettano. L'agente può preparare il lavoro e inviarlo tramite una richiesta pull, ma i criteri del repository e i revisori umani decidono se il lavoro è unito o distribuito.
Esempio pratico in GitHub
Un agente di correzione delle dipendenze ha come ambito l'implementazione:
- L'agente rileva una dipendenza vulnerabile, ad esempio da un avviso di sicurezza o da un problema.
- L'agente crea un ramo.
- L'agente aggiorna la dipendenza e il file di blocco.
- L'agente apre una pull request che include un piano strutturato e segnali di successo previsto.
A questo punto, la responsabilità delimitata dell'agente può essere considerata completa. La convalida e l'accettazione vengono eseguite tramite controlli, verifiche e controlli dei criteri.