次の方法で共有

Eclipse 対応 Team Foundation Server プラグイン

  • [アーティクル]

Team Explorer Everywhere を使用すると、開発プロセスの予測可能性が向上します。 Team Explorer Everywhere には、Eclipse 対応 Team Foundation Server プラグインと Team Foundation Server のプラットフォーム間のコマンド ライン クライアントの両方が含まれます。 作業項目トラッキング機能を使用して、顧客にとって何が重要であるかを把握し、プロジェクトの進行状況を追跡できます。 これにより、チームが顧客の要求に基づいて正しく機能するソフトウェアを作成できるように、プロセスを実行し、その品質を監視できます。 Team Foundation バージョン管理を使用して、ソース コードおよびプロジェクト成果物を管理できます。 バージョン管理を使用すると、リスクを軽減し、アプリケーションの品質を向上できます。 統合されたビルド システムを使用して、アプリケーションをビルドできます。これにより、チームでは、品質ゲートが確実に満たされる状態を保ち、各ビルドでどの要件が達成されたかを確認できます。

反復開発での Team Explorer Everywhere の使用

タスク

関連する参照先

はじめに: Eclipse 対応 Team Foundation Server プラグインの機能を使用するには、Visual Studio Team Foundation Server インスタンスへの接続を確立しておく必要があります。

ローカルの開発環境を設定する: チーム開発環境では、多くの場合、正しいバージョンのソース コード ファイルにアクセスするための手段を確保する必要があります。 そのうえで、更新が必要なアプリケーション部分がある場合は、そのソース ファイルを基にローカル コンピューターを更新します。

タスクの実行またはバグの修正のためにコードを変更する: 開発サイクルの期間中のほとんどは、コードの変更に時間を費やします。 このプロセスでは、タスクまたはバグを選択し、必要なファイルをチェックアウトし、コードを変更した後、変更をチェックインする前に変更が正しいかどうかを確認します。 このタスクには、アプリケーション コードとデータベース コードの両方に対する変更が含まれます。

ビルドを作成して要求する: 統合されたビルド システムを使用して、定期的または必要に応じて自動ビルドを実行できます。

品質ゲートを定義する: チェックイン ポリシーを指定して、バージョン管理にチェックインされるソース ファイルの品質を保護できます。

トラブルシューティング: Team Explorer Everywhere の使用時に問題が発生した場合、一般的な問題とその解決方法に関する情報を確認できます。

反復開発タスクの実行

それぞれの開発タスクで、いくつかの一般的な手順を実行します。 これらのタスクは、チームで使用するプロセスに応じて異なる順序で実行される場合があります。 たとえば、コードを変更する前にテストを定義することがあります。

コーディング タスクを特定し、ローカルの開発コンピューターをソース コード用の正しいバージョンに更新した後で、コードに必要な変更を加えることができます。 ただし、通常は変更したコードをテストする必要があるため、コードの変更は一連の手順の最初の手順になります。 アプリケーションの動作を検証した後で、開発タスクを完了し、次のタスクに進むことができます。

タスク

関連する参照先

実行する作業の特定: 通常、作業は、実行する必要のある 1 つ以上のコーディング タスク、または解決する必要のある 1 つ以上のバグで構成されています。 作業項目トラッキング データベースから割り当てられた、最も優先度の高い項目を取得します。 現在の反復処理の全体的なスケジュールを確認し、予定したタイム フレーム内でタスクを完了できるかどうかを検証する場合もあります。 また、タスクに対する他のチーム メンバーの依存度を確認して、進行が阻害されるのを防止する必要があります。 チームに専任のテスト担当者がいる場合は、対象の機能領域を担当するテスト担当者と作業について検討し、テスト担当者が必要なテスト計画の立案を開始できるようにする必要があります。

開発環境の準備: 実行する必要のある作業を特定した後、必要なソース コードを作成できるように、開発環境の更新が必要になることがあります。 リリース済みのバージョンまたは配置済みのバージョンのアプリケーションのバグを修正する場合は、環境を更新して、最新のバージョンではなくソースの特定のバージョンを用意することがあります。 データベースを操作する場合、ローカルの開発サーバーを構成することもできます。

コード障害の原因の特定: 多くの場合、バグを修正する必要があるときに実行する最初の手順は、デバッガーを使用して問題の原因を特定することです。 問題が最近報告された場合、エラーが含まれるソース ファイルの履歴データをチェックして、問題が発生した時点、および問題を報告した人を判断します。 状況によっては、元の変更をロールバックして、別のコード変更を検討する必要があります。

コードの変更: 必要となる変更を特定して 1 つ以上のコードを変更し、それらの変更をテストして、その変更がチームのコーディング規則を満たすことを検証します。

作業の完了: コードを変更する準備ができたら、それらを 1 人以上の同僚と確認し、最終的なフル ビルドを実行して、チェックイン テストを実行します。 変更をチェックインしてマージ競合を解決した後、関連するすべてのタスク、バグ、およびその他の作業項目を解決します。

開発タスクの完了

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

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

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

タスク

関連する参照先

第三者にコードをレビューしてもらう: 多くのチーム開発環境では、コード変更をチェックインする前に、その変更を 1 名以上の第三者にレビューしてもらう必要があります。 この手順がチームで必要とされていない場合でも、複雑なコードは第三者にレビューしてもらうことを検討する必要があります。

コード レビューを簡単にするために、変更を含むシェルブセットを準備することもあります。 チーム メンバーは、シェルブセットの内容をチェックできます。 さらに、変更をバージョン管理に保存することで、別のタスクの作業をできるように、また、開発環境に予期しない事態が発生しても、変更に影響が及ばないようにできます。

最終的なフル ビルドを実行し、関連するテストを実行する: コード変更を行うときに、変更するアプリケーション部分のみをビルドすることがよくあります。 チーム環境では、変更をチェックインする前に、アプリケーション全体のビルドを検討する必要があります。 チームによっては、継続的なビルドを実行するコンピューターにチェックインを送信できます。

多くのチームでは、チェックイン テストと呼ばれる、アプリケーション テストのサブセットを実行する必要もあります。 これらのテストにより、直接変更した箇所以外のアプリケーションの動作が損なわれていないことが検証されます。

すべての変更をチェックインする: すべての変更を検証したら、それらの変更をバージョン管理にチェックインして、チームで使用できるようにします。 変更をチェックインすることで、それらの変更が次の本番のフル ビルドに表示されるようにもなります。 製品サイクルの現在の段階での変更はリスクが大きすぎる場合は、保留中の変更を元に戻すこともできます。

ゲート チェックイン ビルドで保護されているコードを変更している場合、シェルブセットが作成され、保留中の変更がチェックインされる前に正常にビルドされます。

タスク、バグ、およびその他の作業項目を解決する: 変更をチェックインしたら、その変更に関連付けられている関連するタスク、バグ、またはその他の作業項目を解決できます。 通常、変更を含む変更セットを作業項目に関連付けます。これを行うと、後でバグが発生した場合に、関連する変更のセットを見つけやすくなります。 変更内容および変更理由について他のリーダーが理解できるように、作業項目のコメントに十分な情報を含めるようにしてください。 また、後でこのバージョンのソース コードに戻れるように、ラベルを適用することも検討してください。

作業項目が完了したら、その項目にかかった時間が予想を大幅に上回った場合または大幅に下回った場合は、開発スケジュールの調整が必要になることがあります。

デザインに関するフィードバックを送信する: コードに変更を加えるときに、アプリケーションのデザインまたはアーキテクチャの要素を変更することが必要な場合があります。 デザインを変更する場合、アーキテクチャ文書またはデザイン文書 (これにはモデルが含まれる) を更新して、変更を反映する必要があります。 さらに、不具合を修正した場合は、チーム メンバーにその不具合の性質についてのガイダンスを提供し、それを今後回避する方法を説明することができます。

参照

その他の技術情報

コマンド ライン リファレンス (Team Explorer Everywhere)