すべての SSIS パッケージとその構成ファイルを Subversion リポジトリに保存します。ほとんどの場合、構成ファイルはパッケージと同じフォルダーに保存されます。
問題は-SSISは常に構成ファイル（パッケージ自体に保存されているもの）へのパスを絶対パスとして保存しているようです。
他の誰かが開発用 PC の場所とは異なる場所にあるパッケージを含むフォルダーをチェックアウトすると、構成ファイルが検出されません (絶対パスが保存されていて、他の開発用 PC には存在しないため)。そのため、別の開発者がこの構成を削除し、ローカル ハード ドライブの現在の場所から再度追加する必要があります。次に、変更されたパッケージが保存され、新しいバージョンがコミットされます。SVN からそのバージョンを取得すると、PC のローカル パスと一致しなくなります。
関連するメモ: 別の開発者が構成ファイルの値も変更したい場合があります。後でSVNパッケージからすべての最新バージョンを取得すると、PCで動作しなくなります。
これらの不便さをどのように回避しますか？
別の解決策は、最初の構成として環境変数を使用して構成をデータベースに保存し、どのデータベースを調べるかを指示することです。これが私たちが行っていることです。ソース管理の各サーバーに ssisconfig を設定するスクリプトがありますが、パッケージは、使用している環境変数でデータベースの実際のテーブル データを使用します。
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
@HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
プロジェクトフォルダーの下に「config」というフォルダーを追加し、それをソース管理に追加して、このフォルダーに構成ファイルを保持します。必要に応じて、SSIS プロジェクトに追加することもできます。
誰でもこのフォルダーを使用して構成ファイルをダウンロードできるため、これは良い解決策だと思います。
パッケージが展開されると、展開マニフェストで通知した場所から構成ファイルが読み取られるため、このソリューションは開発に影響しません