私は、SSIS パッケージとその展開方法をもう少しよく理解しようとしています。私が間違っていることを訂正してください。ただし、どの展開でも、少なくとも 2 つのファイル (.SSISDeploymentManifest と .dtsx) が必要であると考えています。.SSISDeploymentManifest は、.dtsx を指す同等の Windows インストーラー パッケージとして機能します。dtsx は、インストーラーを実行するときに何らかの方法で外部ファイルとして参照される「もの」の実際のパッケージです。インストールすると、パッケージはそのインスタンスの ssis パッケージのリストに追加されます。
私のさらなる質問：
私が間違っていることを訂正してください。ただし、どの展開でも、少なくとも 2 つのファイル (.SSISDeploymentManifest と .dtsx) が必要であると考えています。.SSISDeploymentManifest は、.dtsx を指す同等の Windows インストーラー パッケージとして機能します。dtsx は、インストーラーを実行するときに何らかの方法で外部ファイルとして参照される「もの」の実際のパッケージです。インストールすると、パッケージはそのインスタンスの ssis パッケージのリストに追加されます。
あなたの仮定はほとんど正しいです。配置マニフェストは必要ありませんが、あると便利です。また、SQL Server インスタンスにデプロイする必要はありません。ファイル システムにデプロイするオプションもあります。以下で両方を説明します。
最初の質問について：
Visual Studio を使用して dtsx パッケージを開発およびチェックインしていることを確認してください。ソースセーフまたは使用しているバージョン管理でリリースにラベルを付けます。チェックインしてラベルを付けている場合は、以前のバージョンに簡単にロールバックできるはずです。あなたが言及したように、古い bin ディレクトリのコピーを保存することもできますが、当然それらを古いサブフォルダーなどに配置します。ただし、これは適切なバージョン管理の代わりにはなりません。
2番目の質問について：
他のポスターが述べているように、最初に決定を下す必要があります。
a) パッケージをファイル システムに展開する b) パッケージを MSDB に展開する
それぞれに利点があり、誰もが好みを持っています。私は両方を使用しましたが、より透過的であるため、ファイルシステムを好みますが、維持する必要があるものは他にもあります。
これに関する詳細については、この投稿を参照してください 。
コードは dtsx パッケージにあります。通常、パッケージを移植可能にするために、接続文字列やその他の構成可能な情報を構成ファイル (.dtsconfig) または環境変数 (ファイルは不要) に抽象化します。構成の詳細については、BOL を参照してください。
マニフェスト ファイルには、インストールする dtsx ファイルと構成ファイルに関するメタデータが含まれています。ファイルを開くと、単純な読み取り可能な xml ファイルであることがわかります。
マニフェスト ファイルを使用すると、DBA にデプロイを簡単に引き渡すことができます (マニフェスト ファイルをダブルクリックして指示に従うように依頼しますが、指示が必要になります。
私にとって、マニフェスト ファイルは、ファイル システムよりも SQL Server への展開に役立ちます。実際には、dtsx ファイルと構成ファイルのコピーを作成し、指定した場所に配置するだけです。DBA に、dtsx ファイルをサーバー上の共通フォルダーにコピーし、構成ファイルを同じサーバー上の別のフォルダーにコピーするように簡単に指示できます。
次に、SQL エージェントを使用してジョブをスケジュールするときに、ファイル システムに保存されている SSIS パッケージを実行することを指定し、その場所を参照します。構成を使用している場合は、構成ファイルの場所を指定するタブがあります。
SSIS パッケージの構成/展開/バージョン管理について知っておくべきことがたくさんあります。しかし、うまくいけば、これで正しい道を歩み始めることができます。
SQL Server のインポート/エクスポート ウィザードを使用して DTS パッケージをエクスポートする場合、パッケージを SQL Server に保存するか、ローカルのファイル システムに保存するかを選択できます。