0

DACPAC プロジェクトの一部であるストアド プロシージャの 1 つに変数 (トークン) を構成しようとしています。構成ファイルの場合と同じ方法でこれを実行しようとしました。いえ

ext トークンを使用して複製ファイルを作成します。置き換える項目をTOKEN_NAMEに置き換えます。RM でコンポーネントの変数を作成します。ただし、これは DACPAC ソリューションでは機能しないようで、変数は置き換えられません。

DACPAC プロジェクトでこれを行うことは可能ですか? そうでない場合、ストアド プロシージャに構成可能な項目を追加するには、どのような方法をとればよいでしょうか?

これが可能な場合、どこが間違っていますか?

4

2 に答える 2

3

これはリリース管理の問題ではなく、SSDT の問題です。一般的に非常に悪い考えを実行したい場合: データベースを環境ごとに異なるものにする。継続的デリバリーは一貫性がすべてです。ソフトウェアをより低い環境にリリースするたびに実稼働展開を「練習」していることを信頼できない場合は、環境の違いにより実稼働展開が失敗するという非常に悪い時期に備えていることになります。

とはいえ、できることはいくつかありますが、優先順にリストされています。

  1. 環境間でデータベースが異なるのをやめる
  2. デプロイ前およびデプロイ後のスクリプト内で SQLCmd 変数を使用できるため、ストアド プロシージャを変更するデプロイ後スクリプトを作成し、RM を介して値を渡します。sqlpackage.exe発行時に SQLCmd 変数を提供できるように、RM が渡す引数を変更できます。それはまだ本当に悪い考えですが、うまくいくはずです。
  3. リリース デフォルト テンプレートを変更し、トークン スワップ アクションの場所を移動できます。通常、トークンの交換はビルド後に発生します。ビルドの前に発生するように移動できます。
于 2015-03-29T23:37:13.003 に答える
0

RM が sqlpackage.exe の実行に干渉する方法はなく、スキーマのコンパイルが停止する可能性があるとしても、DACPAC を発行するときにトークン ファイルを使用してこれが機能する方法はわかりません。

DACPAC ファイルを解凍し、トークンを置き換えてから圧縮するコンポーネントを作成できるかもしれませんが、これは大変な作業のように思えます。

私のアドバイスは、トークン化された SQL スクリプトを使用して DACPAC を実行した後に、環境固有の要件を適用することです。これについては、こちらのブログ投稿で説明しています。

于 2015-03-28T11:48:53.703 に答える