Responsabilités d’agent cartographique auprès du SDLC
Dans cette unité, vous allez apprendre :
- Pourquoi le mappage des responsabilités aux étapes du SDLC (cycle de vie du développement logiciel) améliore la fiabilité
- Comment les niveaux SDLC se mappent aux artefacts et surfaces de contrôle de GitHub
- Définir des limites architecturales pour le comportement de l’agent afin de réduire les risques et d’améliorer l’audit
Pourquoi le mappage des responsabilités importe
Les systèmes d’agent ne doivent pas fonctionner dans l’ensemble du SDLC sans restriction. Lorsqu’un agent est traité comme un développeur à usage général, il devient difficile de raisonner sur son comportement, de limiter son impact ou ses résultats d’audit.
Une approche plus fiable consiste à mapper l’agent à des étapes de cycle de vie spécifiques où GitHub pouvez appliquer des limites. La plupart des équipes commencent par la délimitation des agents aux phases d’implémentation et de validation, où les pull requests et les flux de travail sont des points de contrôle naturels.
Correspondance des phases SDLC aux artefacts GitHub
Le SDLC peut être simplifié en planification, implémentation, validation et déploiement. Chaque étape correspond à une « surface » différente sur GitHub où le travail et les éléments de preuve peuvent être enregistrés.
| Phase du cycle de vie du développement logiciel (SDLC) | responsabilité de l’agent typicale dans GitHub | Artefact principal |
|---|---|---|
| Planification | Brouillon d’étendue, étapes de plan, définir des critères de réussite | GitHub Incidents, descriptions/commentaires des pull requests, onglet Agents |
| Implementation | Créer une branche, effectuer des modifications, ouvrir/mettre à jour PR | Branchement, commits, pull request |
| Validation | Effectuez des vérifications, attachez des artefacts, itérez sur les échecs | Exécutions de flux de travail, contrôles, artéfacts |
| Déploiement | Généralement restreint ; exiger des approbations pour les actions sensibles | Approbations des environnements et du déploiement |
Définir des limites architecturales pour le comportement de l’agent afin de réduire les risques et d’améliorer l’audit
- Définir tôt la portée pour réduire le rayon de blast : limiter les annuaires qu’un agent peut modifier selon la politique et la propriété.
- Traitez les changements de flux de travail et d’infrastructure comme étant plus risqués que les modifications de code d’application.
- Préfère le travail basé sur les relations publiques, même pour l’automatisation ; Évitez les modifications directes vers la branche par défaut.
Une limite de conception commune est : les agents proposent ; les humains et la politique acceptent. L’agent peut préparer le travail et l’envoyer via une pull request, mais la politique du dépôt et les réviseurs humains déterminent si ce travail est fusionné ou déployé.
Exemple pratique dans GitHub
Un agent de correction des dépendances est destiné à l’implémentation :
- L’agent détecte une dépendance vulnérable (par exemple, à partir d’une alerte de sécurité ou d’un problème).
- L’agent crée une branche.
- L’agent met à jour la dépendance et le fichier de verrouillage.
- L’agent ouvre un pull request qui inclut un plan structuré et des indicateurs de succès prévus.
À ce stade, la responsabilité étendue de l’agent peut être considérée comme terminée. La validation et l’acceptation se produisent par le biais de vérifications, de révisions et de contrôles de stratégie.