2012-05-09 5 views
0

主にソフトウェアを購入しますが、その上に統合サービスやWebサービスを追加します。ベンダー提供のパッチ、DLLファイル、時間をかけて収集し、それらを格納するデータベーススクリプトの大きな山を取る必要があります。次に、それらをデベロッパーにデプロイし、次にテストし、次にスタンギングし、次に生産する必要があります。誰もTFSプロジェクト/フォルダでこのタイプのデータを構造化する巧妙な方法を持っていますか? TFSは最良の解決策ではないかもしれませんが、私はこの疑問に対して与えられなければならないのではないかと心配しています。TFSにサードパーティのISVパッチ、スクリプト、バイナリを保存する効果的な方法

例:環境によるプロジェクトですか?環境による支店?日付順のフォルダ? (ソースコードのようなファイルのバージョニングは実際には意味をなさないことを考慮して)

これらのファイルがソリューションの一部としてどの環境にデプロイされたかを追跡したい場合は、例えば、xdllは12月5日にステージングを行うプロジェクトの一環として展開されたと言えます。

答えて

0

私は、これらの外部依存関係のバージョンを自分の開発と並行して独自のディレクトリで制御し、そのディレクトリを参照することをお勧めします。その後、任意の支店の一部になります。必要に応じて、開発、テスト、およびプロダクションのバージョンを別々にすることができます。ベンダーのパッチを使用してソリューションをテストするための特定のブランチを作成することもできます。例:

$/Development-Branch 
    |+3PP 
    ||+Vendor-1 
    |||+ Bin 
    |||+ ... 
    ||+Vendor-2 
    | |+... 
    |+Our-Project-1 
    ||+ ... 
    |+Our-Project-2 
    |+ ... 
$/Test-Branch (based on $Develeopment-Branch version XXX) 
    |+3PP 
    |+ ... 

欠点が(彼らは大きなしている場合)、これらの外部依存関係は多くのスペースを取るかもしれませんが、それは、今日の問題の多くをすべきではない、それはに難しいかもしれないとということですベンダー自身が実際にサポートしていない場合は、それらのパッチ/アップデートをチェックインしてください。彼らはライブラリ間で異なる名前を使うかもしれません。リリース間では、バージョンコントロールによって正しい方法で苦労することがあります。

関連する問題