SentinelSentinelは条件を監視し、該当する場合に動作します。一方のスケジュールが時間によってトリガーされるのに対し、Sentinelは 何かが真の状態になることでトリガーされます。
ファクトリーの「スケジュール」エリアで確認できます。
監視対象となる条件
定義する条件とは、チェックの失敗、コードベース内でのパターンの出現、 接続されたシステムからの信号、規格準拠からの逸脱などです。
モニターが作動すると、修復作業が開始されます。これは通常のタスクで、 仕様が定められ、他の作業と同様に計画・ビルド・検証・レビューのプロセスを経ます。
安全な仕組みである理由
Sentinelは直接コードを修正しません。コードを修正する作業を開始し、 その作業によって作成されるのが承認が必要なpull requestです。
これは思われる以上に重要です。本番コードを直接編集する自律型システムには、 最もレビューが必要なタイミング——つまり誰も変更を依頼しておらず、誰も監視していない時——にレビュー手順が存在しません。通常のプロセスを経ることで、自律性が処理能力を向上させつつも制御を維持できます。
テンプレート
よく使われるモニターはテンプレートとして提供されるため、最初から一から作成する必要はありません。定期的なヘルスチェック、ドリフト検出、標準的な修復ループなどが含まれます。
テンプレートから開始し、しばらくはアドバイザリーモードで実行してから、無人で作業を開始する前に調整してください。
制御を維持する方法
Sentinelが開始した作業は、他の作業と同じエージェントスロットを争います。頻繁に作動するモニターは、知らず知らずのうちにリソースを消費する可能性があります。
有用性を保つための3つのルール：
- 人間が要求した作業よりも低い優先度を設定します。
P2またはP3. - 条件を具体的に定義します。「テストが失敗している」という条件は、活動の多いリポジトリでは頻繁に作動しますが、「この特定のチェックがベースブランチで1時間以上失敗し続けている」という条件なら、実際に問題がある時にのみ作動します。
- 成果をレビューするモニターが20件のタスクを作成しても2件しかマージされていない場合、それは価値ではなくノイズとコストの浪費に過ぎません。
作動回数ではなくマージ率を注視する
モニターの真の評価基準は、作成した作業のうちマージされる割合です。稀に作動しても常に正しく機能するモニターが理想的です。頻繁に作動してもほとんど無視されるモニターは負担にすぎません。