#3 をさらに詳しく説明すると、チームが単一の SSIS ソリューションで作業できるようにする最善の方法は、問題 (パッケージ) をより小さなチャンクに分解し、親子/マスター/スレーブ タイプを介してそれらの呼び出しを制御することです。関係。
たとえば、ソリューションはデータ ウェアハウスの読み込みに関するものです。FactController.dtsx と DimensionController.dtsx の 2 つのコントローラー パッケージが必要かもしれません。彼らの責任は、ニーズを解決するさまざまなパッケージを呼び出すことです (ファクトまたはディメンションのロード)。おそらく、私の DimensionProductLoader パッケージはスノーフレーク (Product と SubProduct テーブルを更新する必要がある) を扱っているため、2 つのパッケージに分解されます。
これらすべての目標は、開発プロセスを管理しやすいチャンクに分割して、単一のパッケージへの同時アクセスを回避することです。XML をマージしても、生産的な時間の使い方にはなりません。
これらすべての唯一の共有リソースは SSIS プロジェクト ファイル (dtproj) です。これは、プロジェクトを危険にさらすパッケージを列挙した単なる XML ドキュメントです。適切な名前の空白のパッケージを使用して事前にスケルトン プロジェクトを作成すると、プロジェクトをリポジトリにマージしようとする人々にまつわる最初の苦労の一部をスキップできる可能性があります。少なくとも TFS では、誰もが XML グロブをチェックインするよりも、1 回限りのタイプのマージの方がはるかにうまくいくことがわかりました。