フォークメンテナンスの自動化、誰も望んでいない仕事

実質的なソフトウェアを実行しているほとんどの組織には、なくてもよかったフォークが少なくとも 1 つあります。上流の要件に合わせてパッチが適用されたライブラリは必要ありません。ローカルに変更を加えたベンダー依存関係。 3年前に何かが分岐したのは、その場にいる誰も完全には説明できない理由からだ。

最新の状態に保つという作業は、重要ではあるが決して緊急ではないタスクの定義であり、それは罪悪感が爆発的に起こることを意味します。

このタスクが適している理由

提案されたエージェント タスクのほとんどは、3 つのテストのいずれかに不合格になります。これはそれらすべてを通過します。

きちんと指定されています。アップストリームの変更を取得し、既知のローカル変更を含むツリーに適用し、機械的な競合を解決して、テストを実行します。

自然な見直しポイントがあります。出力はプルリクエストであり、それをレビューすることはすでにエンジニアの仕事です。

有界です。定義された一連のアップストリーム コミットと定義されたツリーがあるため、エージェントは無制限にさまようことはできません。

これを、3 つすべてが失敗する「顧客からの問い合わせへの対応」と比較すると、結果の違いは不思議ではありません。

エージェントがすべきこととすべきでないこと

機械的な変更を適用し、変更の構造に基づいて解決が行われる競合を解決し、テスト スイートを実行して、何を行ったか、どの競合をどのように解決したかの説明を記述する必要があります。

失敗したテストを許容できると判断したり、競合があったためにローカルの変更を黙って削除したり、途中で気づいたリファクタリングを含めるために範囲を広げたりするべきではありません。

最後の部分は思っている以上に重要です。改善を求められていないものを改善するエージェントは、置き換えた作業よりもレビューが難しいプル リクエストを生成します。

本当の困難はどこにあるのか

パッチの適用ではありません。どの局所的な変更に負荷がかかるかを知ること。

フォークには変更が蓄積されますが、その一部は意図的に行われたものであり、一部は誰も削除しなかった偶発的なものです。エージェントはコードだけでは違いを見分けることができず、意図的な変更を静かに破棄する競合解決は最もコストがかかる失敗です。

軽減策は意図の文書化です。つまり、各ローカル変更が存在する理由の記録がフォークとともに維持されます。これを備えた組織は大幅に優れた結果を得ることができ、通常、これを作成すること自体に価値があります。

評価する

有用な基準は具体的です。テストスイートは合格しましたか。すべてのローカル変更は保存されていたか、または理由を付けて削除されたと明示的にフラグが立てられていましたか。範囲は上流の変更に限定されていましたか。説明は差分に対して正確ですか。

これらはすべて自動的にチェックできるため、人がすべての実行を平等に注意深くレビューするのではなく、評価担当者がすべての実行をスコアリングできるようになります。

正直な結果

作業がなくなるわけではありません。これにより、1 日の機械的な作業が 1 時間の復習に変わり、そのペースが不定期ではなく定期的になり、これが最大のメリットとなります。小規模で頻繁なマージは、毎年のキャッチアップよりも大幅に簡単です。

次へ

Software Factory のページでは、バックログ作業がどのようにしてレビュー可能なプル リクエストになるかについて説明しています。エージェント オーケストレーション システムのページでは、評価、ポリシー、およびコストの帰属について説明します。