エージェントの責任を SDLC にマップする
このユニットでは、次の内容について説明します。
- エージェントの責任を SDLC ステージにマッピングすると信頼性が向上する理由
- SDLC ステージをGitHubアーティファクトとコントロール サーフェスにマップする方法
- エージェントの動作のアーキテクチャ境界を定義してリスクを軽減し、監査可能性を向上させる
責任マッピングが重要な理由
エージェント システムは、制限なしに SDLC 全体で動作してはなりません。 エージェントが汎用開発者のように扱われると、その動作を推論したり、影響を制限したり、結果を監査したりすることが困難になります。
より信頼性の高い方法は、GitHubが境界を適用できる特定のライフサイクル ステージにエージェントをマップすることです。 ほとんどのチームは、まず、プル要求とワークフローが自然な制御ポイントを提供する実装と検証の段階にエージェントをスコープします。
SDLC ステージをGitHub成果物にマッピングする
SDLC は、計画、実装、検証、デプロイに簡略化できます。 各ステージは、作業と証拠を記録できる異なるGitHub "サーフェス" にマップされます。
| SDLC ステージ | 主要成果物 | |
|---|---|---|
| 計画 | 草案の範囲、計画の手順、成功基準の定義 | GitHubの問題、pull request の説明/コメント、[エージェント] タブ |
| Implementation | ブランチの作成、変更、PR のオープン/更新 | ブランチ、コミット、プルリクエスト |
| 検証 | チェックの実行、成果物を添付、失敗の反復処理 | ワークフローの実行、チェック、成果物 |
| デプロイメント | 通常は制限されます。機密性の高いアクションの承認を要求する | 環境とデプロイの承認 |
エージェントの動作のアーキテクチャ境界を定義してリスクを軽減し、監査可能性を向上させる
- 爆発半径を減らすために早期にスコープを設定する: ポリシーと所有権によってエージェントが変更できるディレクトリを制限します。
- ワークフローとインフラストラクチャの変更は、アプリケーション コードの変更よりも高いリスクとして扱います。
- 自動化の場合でもPRベースの作業を優先し、デフォルトブランチへの直接変更を避けます。
一般的な設計境界は、エージェントが提案することです。人と政策が受け入れる。 エージェントは作業を準備し、pull request を通じて送信できますが、リポジトリ ポリシーと人間のレビュー担当者は、その作業をマージするかデプロイするかを決定します。
GitHubの実際の例
依存関係修復エージェントは、実装に限定されています。
- エージェントは、脆弱な依存関係 (セキュリティ アラートや問題など) を検出します。
- エージェントはブランチを作成します。
- エージェントは依存関係とロックファイルを更新します。
- エージェントは、構造化された計画と予想される成功シグナルを含むプル要求を開きます。
その時点で、エージェントの責務が完了したと見なすことができます。 検証と受け入れは、チェック、レビュー、ポリシー制御によって行われます。