GitHub Copilotモダン化のベスト プラクティス

これらのガイドラインに従って、.NET プロジェクトをアップグレードするときにGitHub Copilot最新化から最良の結果を得ることができます。

開始する前に

最適な結果を得るために、アップグレードを開始する前にプロジェクトを準備します。

ソリューションのビルドとテストが成功することを確認する

エージェントは、ビルドとテストを実行して行った変更を検証します。 開始する前にソリューションが既に破損している場合、エージェントは、既存のエラーと、導入された問題を区別できません。

scenario-instructions.mdで既知のテスト エラーを文書化して、エージェントがそれらを無視することを認識できるようにします。

コミットされていない作業をコミットまたは隠す

コミットされていない変更とエージェントの変更が混在しないように、クリーンな作業ディレクトリから始めます。 ベースラインがクリーンであるため、変更の確認や元に戻すのが簡単になります。

git stash
git status

Git 以外のリポジトリをバックアップする

エージェントは、ソース管理下にないフォルダーでも機能します。 プロジェクトが Git リポジトリにない場合、エージェントはブランチ操作とコミット操作をスキップします。 その場合は、開始する前にプロジェクト フォルダーをバックアップし、必要に応じて復元できるようにします。

クラウド プロバイダーにプッシュしない場合でも、アップグレードを開始する前にローカル Git リポジトリを初期化することを検討してください。 ローカル Git リポジトリを使用すると、次のことができます。

• git revertを使用して個々の変更をロールバックします。
• コミット履歴でアップグレードの進行状況を段階的に追跡します。
• 保持または破棄する変更を制御します。
• エージェントが別のブランチで動作している間は、メイン ブランチで元のコードを安全に保ちます。

cd your-project-folder
git init
git add .
git commit -m "Baseline before upgrade"

テスト対象範囲を確認する

エージェントはテストに依存して、その変更が動作を中断しないことを検証します。 テスト カバレッジが良好なプロジェクトでは、信頼性の高いアップグレードが得られます。

小さく始める

エージェントを初めて使用する場合は、小規模でリスクの低いプロジェクトをパイロットとして選択します。 クラス ライブラリまたはユーティリティ プロジェクトが理想的です。 小規模から始めると、メイン アプリケーションに取り組む前に、ワークフローを理解し、信頼性を構築し、リポジトリ固有の問題を検出できます。

アップグレード中

エージェントがアップグレードを行っている間は、次のガイドラインに従ってください。

最初のアップグレードにガイド付きモードを使用する

エージェントは、ガイド付きモードと自動モードの両方をサポートします。 ガイド付きモードでは、エージェントはレビューと承認の重要な決定ポイントで一時停止します。 ガイド付きモードから始めて、エージェントの機能とその理由を理解します。 ワークフローに慣れたら、自動モードに切り替えます。

評価を慎重に確認する

評価は、エージェントが変更を開始する前に問題をキャッチする最適な機会です。 検索対象:

• エージェントが見逃した、または誤って識別した可能性があるプロジェクト。
• 知っている依存関係は問題です。
• エージェントが知っておくべき、ソリューションに関するどんな通常とは違う点があれば。

何かを見つけた場合は、チャットでエージェントに指示するか、 scenario-instructions.mdに情報を追加します。 assessment.mdを直接編集して、エージェントが計画に進む前に、コンテキストを追加したり、誤ったプロジェクトを修正したり、懸念事項にフラグを付けたりします。

計画段階で時間を取る

エージェントは、その評価に基づいてプランを生成します。 続行する前に、プランを確認します。

• 順序はコードベースにとって意味がありますか?
• エージェントが知らない可能性がある依存関係はありますか?
• プロジェクトを除外するか、別の方法で処理する必要がありますか?

タスクの並べ替え、プロジェクトのスキップ、またはアプローチの変更をエージェントに依頼します。 コードベースはエージェントよりも優れているので、その知識を使用してください。 plan.md ファイルを直接編集して、タスクの順序の調整、タスクの追加、タスクの削除を行います。

フィードバックをすぐに送信する

エージェントは、セッション内の修正から学習します。 エージェントがあなたの意に反する選択をした場合は:

• 「そのパターンを使用しないでください。代わりに X を使用してください」とすぐに伝えてください。
• エージェントがタスクやセッション間で記憶できるように、 scenario-instructions.md に永続的なガイダンスを追加します。

実行中のエンゲージメントを維持する

実行は介入せずには行われません。 エージェントに開始を指示する前に、 tasks.md確認します。

• タスクの順序はコードベースにとって意味がありますか?
• スキップまたは再シーケンスするタスクはありますか?
• タスクが欠けていませんか?

実行を開始する前に、エージェントにタスク リストを調整するか、 tasks.md を直接編集するように依頼します。 実行が開始されると、エージェントがタスクの途中で不適切な呼び出しを行った場合は、すぐに通知します。今後は修正が適用されます。

コードベースはエージェントよりも優れているので、すべての段階でその知識を使用してください。

よくある落とし穴

アップグレードの速度が低下したり複雑になる可能性があるこれらの一般的な問題に注意してください。

50 以上のプロジェクトを含む大規模なソリューション

エージェントはプロジェクトごとに動作するため、大規模なソリューションには時間がかかります。 忍耐強く、進行状況を監視します。 完全なソリューションにコミットする前に、1 つの代表的なプロジェクトをエンドツーエンドで開始することを検討してください。 単一プロジェクトのパイロットは、システムの問題を早期に表面化します。

プライベート NuGet フィード

プライベート NuGet フィードの場合は、アップグレードを開始する前に認証します (たとえば、組織の資格情報プロバイダーまたはフィード構成を使用)。 認証がないと、パッケージの復元エラーによって進行状況がブロックされます。

カスタム MSBuild のターゲットとインポート

カスタム .targets ファイル、条件付きインポート、標準以外のビルド ロジックなどの複雑なビルドのカスタマイズは、評価を混乱させ、予期しないビルド エラーを引き起こす可能性があります。 ソリューションにこれらのカスタマイズが含まれている場合は、エージェントがそれらを考慮できるように、チャットまたは scenario-instructions.md でそれらをメンションします。

セッションタイムアウト

実行時間の長いアップグレードは、複数のセッションにまたがる場合があります。 エージェントはワークフロー ファイル ( .github/upgrades/ の下) で進行状況を追跡するため、前回の続きから再開できます。 新しいセッションを開始するときに、".NET 10 のアップグレードを続行します。Data.Access プロジェクトの途中でした。"

効果的に共同作業を行う

相互作用の品質は、結果の品質に直接影響します。

スコープについて具体的に述べること

具体的であるほど、エージェントのパフォーマンスが向上します。

制約を共有する

実際の制約についてエージェントに事前に伝えます。

• "パブリック API の下位互換性を損なうことはできません。"
• 「2 週間でリリース期限が切れたので、Web プロジェクトに優先順位を付けます。
• "レガシ レポート モジュールは、このアップグレードから除外する必要があります。"

アーキテクチャについて説明する

エージェントはコード構造を分析しますが、チームのメンタル モデルを認識しません。 エージェントが次の内容を理解できるように支援します。

• "Project A は共有ライブラリです。 B、C、D はすべてそれに依存しています。
• "WebApi プロジェクトは、公開されている API です。Internal.Api は内部サービス専用です。
• "Models プロジェクトは、OpenAPI 仕様から自動生成されます。直接変更しないでください。

理由を尋ねる

エージェントは、その理由を説明できます。 決定が正しく見えない場合は、次の質問をします。

• 「なぜボトムアップの順序を選んだのですか？」
• "このパッケージを Y ではなくバージョン X にアップグレードするのはなぜですか?
• "なぜこれをサブタスクに分割したのですか?

理由を理解することは、より良いフィードバックを提供するのに役立ちます。

設定を早期に保存する

コーディングスタイル、パターン、またはアプローチに関する強い好みがある場合は、最初のセッションで scenario-instructions.md に追加します。 このファイルはセッション間で保持され、常にエージェントのコンテキスト内にあり、動作に影響を与える最も信頼性の高い方法になります。

問題から回復する

アップグレードが想定どおりに進まない場合は、これらの戦略を使用します。

タスク後のビルド エラー

エージェントに 「最後のタスクの後にビルドが失敗しています」と伝えます 。エージェントはエラーを分析し、修正を試みます。 エージェントが問題を解決できない場合:

1. 手動修正を提供し、エージェントに何をしたかを伝えます。 エージェントは修正プログラムから学習します。
2. コミットを元に戻し (git revert または前のコミットにリセット)、エージェントに別の方法を試すように依頼します。
3. 問題のあるタスクをスキップし、後でそれに戻ります。

間違った戦略が選択されました

エージェントの全体的なアプローチがコードベースで機能しない場合は、計画ステージを再起動します。

• 「計画をやり直しましょう。 私はボトムアップではなく、最初にWebプロジェクトをアップグレードしたいと思います。
• "戦略を変更して、すべての共有ライブラリを 1 つのバッチでアップグレードします。"

エージェントがループにはまる

エージェントが進行状況なしで同じ修正を繰り返す場合は、 "停止" と 言って監視している内容を説明するか、セッションを手動で停止します。 エージェントは、そのアプローチをリセットし、別の方法を試すことができます。

すべての変更を元に戻す

アップグレードに Git ブランチを使用した場合は、元のブランチに切り替えてすべてを元に戻します。

git checkout your-original-branch
git branch -D upgrade-branch

元のコードは手つかずです。 ソース管理なしで作業している場合は、開始する前に作成したバックアップから復元します。

セキュリティとプライバシー

• コードスニペット：GitHub Copilotは、GitHubのCopilotプライバシーポリシーに従ってこれを処理し、セッションを超えて保持しません。
• ワークフロー ファイル (scenario-instructions.md、カスタム タスク、基本設定) は、 .github/upgrades/の下のリポジトリに保持されます。 GitHubは、これらのファイルを外部サービスに送信しません。
• .github/upgrades/ フォルダーはリポジトリの一部です。 アップグレードの進行状況と状態が含まれているため、フォルダーをコミットします。 エージェントには、セッション間で作業を再開するためのフォルダーが必要です。 アップグレードの完了後に削除できます。
• テレメトリ: IDE のテレメトリ設定を使用して無効にします。

パフォーマンスに関するヒント

• 不要なファイルとタブを閉じる: エージェントはアクティブなワークスペースを分析し、開いているファイルが少ないほどノイズが少なくなります。
• 非常に大規模なソリューションの段階的なアップグレード: すべてのプロジェクトを一度にアップグレードするのではなく、バッチ処理します。 たとえば、最初にすべてのライブラリをアップグレードしてから、すべての Web プロジェクトをアップグレードしてからテストします。
• ビルド キャッシュを使用する: エージェントは、検証中に多くの増分ビルドを実行します。 ウォーム ビルド キャッシュを使用すると、検証が大幅に高速化されます。 タスク間でビルド出力をクリーニングしないでください。

関連するコンテンツ

• GitHub Copilot の最新化とは何ですか？
• GitHub Copilotモダン化を使用して.NET アプリをアップグレードします
• コアコンセプト
• GitHub Copilotモダナイゼーションのトラブルシューティング