これらの新機能を使用する予定のワークフローは何ですか？
どのように使用するかは企業によって異なります。
開発者がプロジェクト/パッケージを開発する場合、開発者はプロジェクトをSSISDBに展開するのですか、ソースをチェックインした後に開発者は停止しますか？ DBAはどこに入りますか？どの環境にSSISDBが含まれていますか？プロジェクト/パッケージは他の環境にどのように配備されますか？
本当に依存します。私は、開発者はサーバーの開発層でシステム管理者の権利を持っていると主張します。彼らはそれを壊す場合、それを修正する（または彼らが本当にそれをpoochedした場合、我々はサーバーを再イメージする）。このシナリオでは、実装プロセスを開発し、開発へのデプロイメントを使用して、他のすべての実稼動前および運用環境にデプロイするときにDBAが実行するアクションをシミュレートします。これは、一般的にあなたが好きな規制基準（SOX/SAS70/HIPPA/CPI /など）を満たすものは、それをインストールするのと同じものではないためです。
プロジェクト配備モデルを使用するSSISパッケージの成果物作業単位は何ですか？これは.ispacファイルです。これは、マニフェスト、プロジェクトレベルのパラメータ、プロジェクトレベルの接続マネージャ、およびSSISパッケージを含む自己完結型のzipファイルです。
どのように生成するかはあなた次第です。たぶんあなたはispacをチェックして、あなたの環境に展開されているものでしょう。おそらくDBAはソース管理からソリューションを開き、独自のispacを構築するかもしれません。たぶんContinuous Integration、CIが稼動していて、ボタンをクリックすると、自動化されたプロセスがispacを生成して展開します。
これは1/3の式です。 SSISDB側からは、環境を作成し、それに変数値を設定する必要があります。接続文字列やファイルパス、ユーザー名は&のようなものです。それらの作成を開始するときは、CREATE SCRIPTをNEW WINDOWボタンにクリックしてください！それ以外の場合は、新しい環境に持ち上げるときに、すべてのデータを再入力する必要があります。あなたの開発者がこれらのスクリプトをソース管理にチェックすることを期待します。パスワードの場合は、値をブランクにして展開チェックリストにF5をマッシュする前に修正する必要があることをメモします。
また、SQLスクリプトを使用して、展開するプロジェクトのSSISDB内に構造（フォルダ）を作成する必要があります。デプロイされたら、前の手順で作成した環境値を新しくデプロイされたプロジェクトに適用する必要があります。それらも保存してください。
それぞれの環境にSSISDBが含まれています。私は、生産段階のプロセスが開発段階に到達してデータを取得できるようにするために欠落した構成を望んでいません。私はそれを見た、それはかなりではない。コードがQA /ステージ層にデプロイされると、devサーバがQAからの接続を拒否するため、どこかで接続文字列が欠落しているかどうかが素早くわかります。つまり、SQLインスタンスがすべて同じサーバーアカウントで実行されるわけではありません。各ティアには独自のアカウントが用意されています。ドメイン\ SQLServer_DEV、ドメイン\ SQLServer_QA、ドメイン\ SQLServer_PROD悪い一日を避けるためにできることを実行します。すべての層でシングル/シェアードSSISDBを使用している場合、はになりますが、悪いことが起こらないようにパッケージが常に正しい構成環境で動作するように多くのエネルギーを投入する必要があります。