2017-01-02 5 views
1

私たちはTFS/TFVCサーバーを使いやすくし、TFS作業アイテムの恩恵を受けるために取り組んでいます。私はこれをどうやって行うのかを担当しています。共通コードを含むTFSワークスペース

私たちには多くのプロジェクトがあり、そのほとんどは共通コードライブラリで作業しています。新しい機能を実装する私たちのやり方は、ライブラリのDLLを参照するのではなく、変更が必要なときに、コードへの参照を含め、すべてを一緒に構築することでした。

私の質問は、共通ライブラリと作業中のメインプロジェクトのコードを更新する際に、この作業を面倒にすることのない作業領域の設定を中心にしています。

私は、開発中の製品ごとに複数のチームプロジェクトを作成しました。個々の開発者が個々のプロジェクトに接続されているすべてのワークスペースを確実に移動し、それぞれの私はこれが不器用で、これを行うためのよりよい方法が必要であると感じています。

構造は次のようになり可能性:

ROOT 
|- Common Code 
|- Team projects (each having their own backlog and referencing "Common Code" 
|--- Product one 
|--- Product two 
|--- Product three 

をより良いアプローチは、1つのワークスペース上で動作し、ちょうどチームを作成し、それぞれのバックログを持っているだろうか、開発者に可能にするクリーンな方法があります個々のチームプロジェクトの共通コードライブラリを利用しますか?

+0

PS、どのバージョンのTFSを使用していますか?パッケージ管理は最近導入されたばかりですが、残りの設定は2012年以降、どのバージョンのTFS/VSTSでも動作します.TFSのバージョンがまだパッケージ管理をサポートしていない場合は、ProGetの使用を検討することができます。それは始めるのに十分な無料版を提供します。 – jessehouwing

+0

@jessehouwing最近私たちはTFS 2017にアップグレードしました。だから、私はパッケージマネージメントを見なければなりません。私は開発者であることからIT Operations/DevOpsにすぐに移行しているので、操作の面では非常に新しいものです。私はあなたの援助に非常に感謝しています。 – msweltzdk

答えて

3

チームプロジェクトの設定には多くの考慮事項があります。異なるプロジェクトに分離する最も重要な理由はセキュリティです。異なるプロジェクトが他のプロジェクトのメタデータを見ることができないようにする必要がある場合、単一のチームプロジェクトは悪い考えです。

チームのプロセスに大きな違いがある場合、プロセスはプロジェクトレベルでしか定義できず、同じチームプロジェクトの下にあるすべてのチームが同じプロセス(スクラム、CMMI、アジャイル、またはカスタムプロセス)。しかし、スクラムとアジャイルの違いがあまりないので、CMMIやヘビーカスタムテンプレートに依存しない限り、スクラムやその他のアジャイルのいずれかを練習することができますファンタジーの少しのテンプレート。

それ以外の場合は、creating a single Team Project and using Team Backlogs to represent your projectsと考えることが重要です。このアプローチは、一般的に「それらをすべて統治する1つのプロジェクト」と呼ばれています。

"共通コード"プロジェクトに関しては、Visual Studio Team Servicesのパッケージ管理機能を使用して、共通コードに対する変更のNuGetパッケージを生成することを個人的に検討したいと思います。 The ALM Rangers have written some guidance on setting this up in the past, it's not updated to the latest version of VS and TFS, but it does give a nice outline of the process.これらの共通ライブラリを他のプロジェクトへのNuGetパッケージ参照として含めます。これにより、特定のプロジェクトが特定のバージョンの共通ライブラリにアップグレードされたときをより詳細に制御できるようになり、共通ライブラリを使用する異なるプロジェクト間を素早く分離することができます。これを実行した後は、Continuous Integration、Gated Checkinsなど複雑なワークスペースで作業するなどの設定も簡単になります。

だから、次のようになります:あなたはGitリポジトリにプロジェクトを移動する場合は、同じプロジェクトの下で複数のGitリポジトリを持つことができるように、それはまた、少し楽になり

+- YourAccount.visualstudio.com 
    +- CompanyProject (Team Project) 
    +- TFVC Repository (Can only be one) 
     +- Common (folder) 
     +- Project 1 (folder) 
     +- Project 2 (folder) 
     +- Project 3 (folder) 
    +- Package Management nuget repository 
     +- Common 
    +- Teams 
     +- Root/Company 
      +- Project 1 
      +- Project 2 
      +- Project 3 

+0

このアプローチでは、異なるプロセステンプレートを利用する可能性があると思います。たとえば、あるチームがスクラムと、もう1つはアジャイルと連携しているとします。 – msweltzdk

+0

私たちは "Common code"ベースを構成するいくつかのクラスライブラリを持っていますが、これらは別々のNuGetパッケージであると想像していました。 – msweltzdk

+1

いいえ、「すべてのプロジェクトを統治する1つのプロジェクト」設定では、すべてのチームが同じプロセステンプレートを使用する必要があります。 – jessehouwing

関連する問題