開発タスクの完了

タスク、バグ、またはその他の作業項目に対処するためのコード変更の実装とテストを完了したら、通常、追加タスクをいくつか実行します。 チーム環境では、開発チームの 1 名以上のメンバーにコードのレビューを依頼することがしばしばあります。 アプリケーションの最終的なフル ビルドを実行する必要もあります。

コードのチェックイン前に合格する必要がある一連のチェックイン テストを行う場合もあります。 すべての条件が満たされたら、保留中のコード変更をチェックインできます。マージの競合はすべて解決します。

必要な手順をすべて完了したときにのみ、対応するタスク、バグ、またはその他の作業項目が解決されます。

一般的なタスク

タスク	関連する参照先
第三者にコードをレビューしてもらう: 多くのチーム開発環境では、コード変更をチェックインする前に、その変更を 1 名以上の第三者にレビューしてもらう必要があります。 この手順がチームで必要とされていない場合でも、複雑なコードは第三者にレビューしてもらうことを検討する必要があります。 コード レビューを簡単にするために、変更を含むシェルブ セットを準備することもあります。 チーム メンバーは、シェルブ セットの内容をチェックできます。 さらに、変更をバージョン管理に保存することで、別のタスクの作業をできるように、また、開発環境に予期しない事態が発生しても、変更に影響が及ばないようにできます。	コードの品質を保つためのガイドライン シェルブセットの操作
最終的なフル ビルドを実行する: コード変更を行うときにはしばしば、変更するコンポーネントのみをビルドします。 チーム環境では、変更をチェックインする前に、アプリケーション全体のビルドを検討する必要があります。 チームによっては、継続的なビルドを実行するコンピューターにチェックインを送信できます。	ビルドの実行と監視
すべてのチェックイン テストを実行する: 多くのチームでは、チェックイン テストと呼ばれる、アプリケーション テストのサブセットを実行する必要があります。 これらのテストにより、直接変更した箇所以外のアプリケーションの動作が損なわれていないことが検証されます。	ゲート チェックイン ビルドの定義と変更内容の検証 ビルドのチェックイン ポリシーを使用した、継続的なビルドがブレークした後のコード チャーンの最小化
すべての変更をチェックインする: すべての変更を検証したら、それらの変更をバージョン管理にチェックインして、チームで使用できるようにします。 変更をチェックインすることで、それらの変更が次の本番のフル ビルドに表示されるようにもなります。 製品サイクルの現在の段階での変更はリスクが大きすぎる場合は、保留中の変更を元に戻すこともできます。	保留中の変更のチェックイン 2 つのファイルの競合を解決する [保留中の変更] ウィンドウからの作業項目の詳細の表示 チェックイン ポリシーのオーバーライド 保留中の変更を元に戻す
タスク、バグ、およびその他の作業項目を解決する: 変更をチェックインしたら、その変更に関連付けられている関連するタスク、バグ、またはその他の作業項目を解決できます。 通常、変更を含む変更セットを作業項目に関連付けます。これを行うと、後でバグが発生した場合に、関連する変更のセットを見つけやすくなります。 変更内容および変更理由について他のリーダーが理解できるように、作業項目のコメントに十分な情報を含めるようにしてください。 また、後でこのバージョンのソース コードに戻れるように、ラベルを適用することも検討してください。 作業項目が完了したら、その項目にかかった時間が予想を大幅に上回った場合または大幅に下回った場合は、開発スケジュールの調整が必要になることがあります。	バグ、タスク、およびその他の作業項目の検索 作業項目の解決、終了、または再アクティブ化 作業項目の変更セットへの関連付け チェックイン メモと変更セットの関連付け 変更セットの操作 ラベルを使用したファイルのスナップショット取得 Microsoft Project を使用することによるタスクのスケジュール設定およびリソースの割り当て
デザインに関するフィードバックを送信する: コードに変更を加えるときに、アプリケーションのデザインまたはアーキテクチャの要素を変更することが必要な場合があります。 デザインを変更する場合、アーキテクチャ文書またはデザイン文書 (これにはモデルが含まれる) を更新して、変更を反映する必要があります。 さらに、不具合を修正した場合は、チーム メンバーにその不具合の性質についてのガイダンスを提供し、それを今後回避する方法を説明することができます。	既存のコードの視覚化 ソフトウェア設計のためのモデルの開発 ユーザー要求のモデリング 開発時のシステムの検証

関連するシナリオ

• 一般的な開発タスクの実行
  開発タスクを完了したときには、チームのプロセスまたはメソドロジで必要な手順をすべて実行済みです。

• コード変更によるテストへの影響を識別する
  変更をチェックインし、関連付けられている作業項目を解決する前に、テストを実行して、コード変更で影響が及ぶアプリケーション部分を検証する必要があります。 Visual Studio Premium および Visual Studio Ultimate のテスト影響分析機能を使用して、実行する必要があるテストを確認できます。

• 単体テストを使用したコードの検証
  アプリケーションの動作を検証するために、既存のテストを実行する必要があり、さらに追加のテストを作成することが必要な場合もあります。 アプリケーションで 1 つ以上のデータベースを使用する場合、そのテストで使用するための現実的なテスト データを生成することが必要な場合があります。

• コード分析ツールを使用したアプリケーション品質の分析
  コードを分析して、アプリケーションのユーザーに対して問題となる可能性がある一般的なデザインの問題について調べることが必要な場合があります。

• 開発スケジュールと作業の管理
  変更をチェックインし、作業項目を解決したら、現在のイテレーションの開発スケジュールをレビューすることが必要な場合があります。 スケジュールどおりに進んでいるかどうかを調査できます。 予定よりも長い期間がタスクに費やされた場合、その作業に依存しているチーム メンバーを調べて、遅延の影響について相談できます。