更新セットでスタートする
更新セットはインスタンスを変更するため、この情報をレビューして、エラーやパフォーマンスの問題を回避します。更新プロセスを計画し、よくある間違いを避ける方法を学びます。
更新セットを使用するタイミング
| 展開オプション | 適する場面 | 今後の検討事項 |
|---|---|---|
| 更新セット | ベースラインまたはインストールされたアプリケーションに変更を保存する。 特定のバージョンのアプリケーションを保存して適用する。 エクスポート用のファイルを作成する。 |
特定のアプリケーションバージョンを格納する更新セットを手動で作成できます。 更新セットを使用して、インストールされているアプリケーションへのパッチまたは変更を展開します。 注: アプリケーションをインストールするために更新セットを使用しません。代わりに、アプリケーションリポジトリまたはServiceNow Storeを使ってアプリケーションをインストールします。 |
| アプリケーションリポジトリ | すべての会社インスタンスでのアプリケーションのインストールと更新。 アプリケーション更新セットを自動的に管理する。 同じ会社にアプリケーションへのアクセスを制限する。 完成したアプリケーションをエンドユーザーに展開します。 |
アプリケーションを他のユーザーと共有するようServiceNow Storeにアップロードすることを検討します。 最新のアプリケーションバージョンのみのインストールと更新を許可します。 更新セットを使用して、以前のアプリケーションのバージョンを保存します。 注: チーム開発と使用する場合は、親インスタンスからアプリケーションのみを発行します。 |
更新プロセスの計画
更新セットで作業する前に、このチェック リストを使用して、インスタンス間でカスタマイズを移動するための標準プロセスを作成します：
- 両方のインスタンスが同じバージョンであることを確認します。バージョン間で変更されたコードに依存する場合、カスタマイズは機能しない可能性があります。
- １つの更新セットで行う変更を決定します。小規模から中規模の作業を完了すると、更新セットを完成します。更新セットが大きくなるにつれて、それらをレビューすることが難しくなり、特定の変更を識別するのに時間がかかり、他の更新セットとの競合のリスクが高まり、プレビューや収容に時間がかかます。これは、更新セットにスキーマの変更や大きなワークフローのリビジョンが含まれている場合や、セットを取り消す必要がある場合に特に当てはまります。
- すべての基本システムレコードがに合致するsys_idフィールドを持つことを確認します。一部の基本システムレコードは、プロビジョニング後のインスタンスで作成され、異なるインスタンス間で一致しないため、更新セットに問題が発生します。この問題を回避する最善の方法は次のとおりです：
- 本番インスタンスと非本番インスタンスを使えるようにします。
- 本番インスタンスを非本番インスタンスにクローンします。
- 更新セットがインスタンスからインスタンスに移動し、そのモデルを維持するように共通パスを特定します。複数のソースから同じ更新セットを移行しません。更新セットをdevからtestに移動し、次にテストから運用に移動します。
- 運用に更新セットを収容する時期を計画します。営業時間中に本番インスタンスに更新セットを収容することは避けます。更新セットが適用されると、インスタンスの効率が一時的に低下することがあります。
- 更新セット名が明確であることを確認します。複数の開発者の変更を調整し、変更を別のインスタンスに収容するときに参照するための命名規則を作成します。
- 更新セットが問題の修正として生成されている場合は、問題チケットを名前に含めることを検討します(たとえば、 PR10005 - 重複する電子メールの問題の修正 )。
- 問題を解決するために複数の更新セットが必要な場合は、命名規則にシーケンス番号を含めて、更新セットが作成された順序で適用されるようにします。(たとえば、 PR10005 - 重複する電子メールの問題の修正そして PR10005.2 - 重複する電子メールの問題の修正 )。
- 更新セットについて次のことを理解します。
- どのレコードが生成されるか。
- どのカスタマイズが追跡されるか。
- 有効なディクショナリーの変更。
- 一度適用されて、取り消す(元に戻す)ことができるカスタマイズ。
- カスタマイズを行う前に、正しい更新セットが選択されていることを再度確認します。
更新セットで作業
エラーとパフォーマンスの問題を回避するには、この情報をレビューします。
- 更新セットを削除しません。更新セットが削除された場合、更新されたレコードは次の更新で上書きされる可能性があります。
- system_id フィールドを更新セットのldap_server_configレコードからインクルードしません。作業構成からの更新セットが、ターゲット インスタンスの間違ったsystem_idノードを指し示し、動作しません。
- デフォルトの更新セットを取り消せません。これにより、システムが損傷する可能性があります。
- 顧客更新レコード(sys_update_xml)中の更新セット フィールド値(update_set)を決して変更しません。誤った更新セットでカスタマイズを行った場合は、次のアクションを行います：
- 目的の更新セットに切り替えます。
- 最初に変更されたオブジェクト(レコード)を変更します。フィールドを追加するなど、簡単な変更を行えます。
- レコードを保存します。
- 実行したばかりの変更を取り消し、レコードを再度保存します。
このアクションにより、オブジェクトの最新バージョンが目的の更新セットに含まれ、単一の更新セット内の同じオブジェクトの重複した更新が防止されます。
- 移行する準備が整うまで更新セットを完了とマークしません。更新セットが完了すると、それを元の進行中に戻さません。代わりに、残りの変更について別の更新セットを作成し、作成された順序で一緒に収容します。このケースでは、命名規則が役立ちます(たとえば、パフォーマンスの向上とパフォーマンスの向上2)。
- 手動で更新を更新セットに結合しません。常に更新セット結合モジュールを使用します。このツールは、更新セット間の重複ファイルを比較し、最新のバージョンを選択します。
- 収容された更新セットがテストインスタンスに問題がある場合は、開発インスタンスの別の更新セットに修正プログラムを作成します。このセットをテストインスタンスに収容してから、両方のセットが本番インスタンスにマイグレーションされ、作成された順序で収容されていることを確認します。
- 収容する前に常に更新セットをプレビューします。
- 本番インスタンスの完了した更新セットを無視する にセットします。この状態は、インスタンスのクローン作成時に更新セットが再適用されない事を確実にします。
- 更新セットが適用された後に完了する必要がある手動変更とデータロードのリストを作成します。
- 一度に多くの変更を加えません。正しい変更が段階的に行われたことを確認する。
- 単一の更新を複数のドメイン (グローバルドメインと TOP ドメイン) にまたがる更新に変更することはできません。この機能は Now Platform ではサポートされていません。