ServiceNow研究所ServiceNowのUpdate Set（更新セット）をインスタンス間で移送する際の注意点やTipsを共有します。なお、Update Set自体については「ServiceNow – Update Set（更新セット）の図解解説」を、ServiceNowにおける開発資源の移送全般については「ServiceNowにおける開発・資源移送（デプロイ）の全体像」を併せて参照ください。
開発時・移送前
Update Set（更新セット）に記録されない変更に注意
Update Set（更新セット）には全ての変更が記録されるわけではありません。基本的な考え方として、設定系のテーブルは記録され、データ・トランザクション系のテーブルは記録されないことを覚えておきましょう。
また、開発者からみると移送されるべきと考えられる変更の中に、一部Update Setに記録されないものがあります。これらの変更は、レコードをXML形式でエクスポート・インポートする機能を使って移送します。
詳細は次の記事で詳しく解説しているので、併せて参照ください。
ServiceNow - Update Set（更新セット）の図解解説
Update Set（更新セット）への記録漏れに注意
移送対象のUpdate Set（更新セット）に記録すべき変更が、”Default” Update Setや、移送予定のない無関係なUpdate Setに含まれていると、機能を正しく移送することができません。特に、Service Portal、Employee Centerの開発・変更を行う場合などで、複数のアプリケーションスコープをまたいで開発を行う場合に漏れやすいです。
開発者各自が注意を払うべきですが、記録漏れを完全に防ぐのは難しいため、Update SetをComplete状態に変更する前に、以下の手順で必ず確認を行いましょう。
- Customer Update（顧客アップデート）テーブルのリストを開く
メニューに”sys_update_xml.list”と打ち込むことでリストを開くことができます
- 開発を行った期間、および開発者のユーザで絞りこむ
- 適切なUpdate Setに含まれていることを確認する
この時、Update Setを明示的に指定していない場合に指定される”Default” Update Setになっている場合は漏れている可能性が高いです
Update Set（更新セット）への記録漏れを発見した場合
更新セットへの追加が漏れていた場合は、細心の注意を払いつつCustomer Update（顧客アップデート）レコードのUpdate Setフィールドの値を修正し、適切なUpdate Setに記録されるようにします。
なお、適切なUpdate Setを選択した状態で再度更新を行う方法もありますが、この場合、対象レコードを意図的に変更してから元に戻すなどの操作が必要となり、操作ミス（二次被害）を誘発する可能性があります。また、”Default” Update Setなどにゴミが残るため、個人的には上述の方法を推奨します。
誤ったUpdate Set（更新セット）への記録に注意
Update Setへの記録漏れに加え、誤ったUpdate Setに変更を記録してしまうことにも注意が必要です。確認方法と対応は、上述の記録漏れの場合と同様です。
ただし、誤って記録したUpdate Setが、本来記録されるべきUpdate Setと同時に移送する予定のUpdate Setである場合、後述のUpdate set batching機能を利用することで、複数のUpdate Setを一つのUpdate Setであるかのように扱うことができ、問題なく移送できます。そのため、開発資源の管理の観点で適切なUpdate Setに必ず含めたいということでなければ、リスクを冒して正しいUpdate Setに移し替える必要はなく、そのまま放置することも一つの選択肢です。
移送時
プラグインは移送先の環境で事前に有効化する
プラグインは各環境で個別に有効化する必要があります。開発環境で有効化したプラグインが前提となるUpdate Setを、プラグインが有効化されていない移送先の環境に適用すると、エラーが発生する可能性があります。これを防ぐため、移送先の環境でも同じプラグインを事前に有効化しておきます。
他の環境から直接Update Setを取得する場合はユーザの認証設定に注意
「ServiceNowにおける開発・資源移送（デプロイ）の全体像」でも解説しているように、Update Setの移送には、次の2つの方法があります。
- 本番インスタンス側で開発インスタンスの情報（URLや管理者権限を持つアカウントのID・パス）を設定し、Retrieve（取り込み）を行う
- 開発インスタンスからUpdate SetをXMLファイルとしてエクスポートし、それを本番インスタンスにアップロードする
前者の方法を採用する場合、開発インスタンスのユーザ情報を設定する際に以下の点に注意が必要です。
- ユーザの2FAが有効になっている場合
ServiceNowの2段階認証が設定されていると、パスワードの末尾にワンタイムパスワードを追加します。パスワードのみを入力すると認証エラーとなります。 - ユーザのパスワードリセットが強制されている場合
Update Set用に作成したユーザが一度もログインしていない場合などでパスワードリセットが強制されている（”Password needs reset” フィールドにチェックが入っている）と、エラーが発生します。
Update Set同士の依存関係はUpdate set baching機能で解消可能
複数のUpdate Setに依存関係がある場合、依存元のUpdate Setを依存先より先に、または同時に移送する必要があります。
ただし、依存関係にある複数のUpdate Setを同時に移送する場合、Update Setに親子関係を持たせることで、親のUpdate Setを移送すれば子も含めて一括で移送できる Update Set batching 機能を利用することが可能です。この機能を使うことで、依存関係を意識する必要がなくなります。
Update SetとXML移送の依存関係は特に注意する必要はない
Update SetとXML移送の依存関係については、基本的に大きな注意を払う必要はありません。
例えば、タスクのアサインを自動決定するためのAssignment Data Lookup設定と、そのアサイン先のグループ設定を考えた場合、グループ設定はUpdate Setに記録されないため、XMLで移送する必要があります。
この状態でLookup設定を先にUpdate Setで移送した場合、たとえAssignment Groupフィールドで指定しているグループのレコードが存在しなくても、フィールドの内部的な値であるSysIDは正しく移送されます。そのため、XMLを用いてSysIDを維持したままグループを後から移送すれば、結果的に正しく紐づきます。
ただし、グループを移送するまでは、Assignment Groupフィールドが設定画面上で空白に見える（＝設定されていないように見える）ため、基本的には依存元のデータ（XML）を先に移送することを推奨します。
この考え方は、XML移送するデータ間の依存関係にも同様に適用されます。
Preview（プレビュー）は事前に実施する
Update Setの移送は次の3ステップで行います。特に利用ユーザのログインを止めたり、システムメンテナンスとして事前周知を行った上で行う移送の場合、Preview（プレビュー）までは作業日よりも前に完了させておき、作業当日に行うのはCommit（コミット）だけにしましょう。
- Update Setの移送（資源移送） … 開発環境から検証・本番環境にUpdate Setを移送する
- Preview（プレビュー） … Update Setを適用した場合に、既存の設定との衝突等がないかを確認する
- Commit（コミット） … Update Setに含まれる変更を実際に適用する
Previewで問題が発覚した場合の対応
Previewで問題が発覚した場合、次の2つの対応方法があります。それぞれにメリットとデメリットがあるため、原因や状況に応じて使い分けます。
- Update Setを修正して移送し直す
移送先の環境からRemote Update Set（リモート更新セット）を削除し、移送元環境でUpdate Setを修正して、再度移送します - Update Setを適用した上で、修正用のUpdate Setを追加移送する
問題のあるUpdate Setを適用、もしくは適用をスキップしてCommitした上で、修正用のUpdate Setを追加で移送します
移送後
移行後に注意すべき点は、移送元環境と移送先環境で異なる設定が必要な場合の設定漏れです。
外部連携（IF）における接続情報の変更漏れに注意
外部システムとの連携を行う場合、通常、ServiceNow側と対向システム側の双方に開発、ステージング、本番といった複数の環境が存在することがあります。
ServiceNowの移送元と移送先で接続する対向システムの環境が異なる場合は、移送後に手動で接続情報を変更しましょう。
Privateなシステムプロパティの設定漏れに注意
PrivateなSystem Property（システムプロパティ）の設定はそのインスタンスのみで有効な設定となり、別のインスタンスに移送されません。そのため、移送後に手動で設定を行う必要があります。
代表例はインスタンスのメール送信可否（メール送信On/Off）を制御するSystem Property “glide.email.smtp.active”で、設定が漏れるとメール通知が送信されない、といった障害に繋がります。
詳細は下記の記事をご確認ください。
ServiceNowのSystem Property（システムのプロパティ）とは何か
Update Setの移行で失敗しないために
これまで説明してきたように、Update Setの移送には多くの注意点があります。移行の失敗を避けるために、開発段階で以下の3つのドキュメントを作成し、注意が必要なポイントに気づき次第メモしておくことをお勧めします。
- Update Set一覧
移送すべきUpdate Setの一覧と、依存関係を整理したもの。 - XML移送対象一覧
Update Setには記録されずXMLで移送する対象の一覧。テーブル名やデータのフィルタ条件などを記載。 - プラグイン一覧
プラグインと、それがどの環境で有効化されているか、または有効化する予定かを記録。 - システムプロパティ一覧
利用するシステムプロパティの一覧と、環境ごとの値を記録。 - 移行手順書
Update SetやXMLの移送手順、移送後に手動で設定すべき項目についての手順を記載。
以上です。移送の成功率が少しでも上がれば幸いです。