ServiceNowにおける開発・資源移送（デプロイ）の全体像

ServiceNowにおける”開発”とは何か、どのように行うのか、開発物はどのように管理されるのか、そしてそれがどのように移送（デプロイ）されるのかを豊富な図解と共に解説します。

ServiceNowにおける開発・資源移送の概要

まずは概要を示します。開発者は開発インスタンス（開発環境）で開発を行って開発資源（設定内容やコード）を作成します。その後、開発インスタンスから本番インスタンスに作成した資源を移送します。

以下、この図の要素を一つずつ説明していきます。

インスタンスとは？

インスタンスとはいわゆる”環境”のことで、開発インスタンス=開発環境、本番インスタンス=本番環境と考えてよいです。今回は簡単のために最小の2環境構成の例で説明しますが、多くの場合検証（テスト）環境を入れた3環境構成以上となっています。

この記事を読み進める上ではこの理解で問題ありませんが、インスタンスについては次の記事で詳しく説明しています。

ServiceNowのインスタンスとは何か

ServiceNowの「インスタンス」とは何でしょう？この記事では、インスタンスとは何か、マルチテナントかシングルテナントか、インスタンスの種類、インスタンスの管理について説明します。ServiceNowのインスタンスとは？...

servicenow-lab.com

2022.10.09

ServiceNowにおける開発とは？

ServiceNowにおける開発とは、インスタンスにWebブラウザからアクセスして、何らかのConfiguration（設定）やCustomization（カスタマイズ）を行うことです。

Configuration（設定）とCustomization（カスタマイズ）

ServiceNowにおける開発は、Configuration（設定）とCustomization（カスタマイズ）に分類されることがあります。サポートサイトによると、次のように区別されています。
（参考: KB0553407: Instance Customization FAQ and Guidelines）

• Configuration（設定）
  標準機能の一部であるコードを変更せず、ベストプラクティスとAPIを用いて業務要件に合うようにインスタンスを設定すること
• Customization（カスタマイズ）
  標準機能の一部であるコードを変更すること

しかし、この定義は曖昧であり、ServiceNow界隈の著名なエンジニアであるCHUCK TOMASIさんは、これらを区別しようとすることは重要ではなく、標準機能に対して何か変更を行う時には、その変更によって得られる価値と、その変更を行うことによる影響・リスク・将来的な保守負担を考えて行うことが重要であるとBlogに投稿されています。私もこの考えに同意しているためこれらの区別は特に重視しませんが、よく使われる言葉として紹介しておきます。
（参考: CONFIGURATION VS. CUSTOMIZATION? – WRONG QUESTION!）

ノーコードとローコード

ServiceNowでは多くの開発をノーコード（コードをゴリゴリ書くのではなくGUI上でマウスを操作しする）、またはローコード（比較的小規模なコードを書く）で行います。なお、ノーコード・ローコードに対してコードをゴリゴリ書いて行う開発をプロコードと呼ぶことがあります。

ServiceNowにおける開発のイメージを持っていただくために、両方の例を示します。

ノーコード開発の例: システムのデフォルトタイムゾーンを設定する

ServiceNowではデフォルトのタイムゾーンがUS/Pacificになっており、日本企業が使う場合は通常日本時間に変更します。デフォルトタイムゾーンを変更するときは、システム設定画面において、該当の設定値をJapanに変更し、”Save”ボタンを押下します。

プロコードに慣れている人は、「こんなの開発じゃないじゃん！」と思われるでしょう。もう少し開発っぽいローコードの例を次に示します。

ローコード開発の例: ユーザ名の表示形式を変更する

ServiceNowの標準のユーザ名の表示形式は、”<First name:名> <Last name:姓>”となっています。こちらを日本式の”<Last name:姓> <First name:名>”に変更させたいとしましょう。

ユーザ名の表示値はユーザテーブルのName項目においてコードを用いて設定されています。このコードの、姓を格納している”last_name”項目と名を格納している”first_name”項目を結合している部分を書き換えます。

もっと長いコードを書く場合もありますが、ここではあくまでServiceNowの開発のイメージを理解いただくことを優先し、シンプルな2つの例を紹介しました。

開発とOOTB

ServiceNowでは、開発を行った状態に対して、買ったばかりの何も変更を加えていない状態のことを”OOTB”と呼びます。そして、可能な限り開発を避け、標準を尊重すべきだと言われています。OOTBについては下記の記事にまとめていますので、併せてご参照ください。

ServiceNow - OOTB（Out-of-the-Box）とは何か、なぜカスタマイズを避け標準を尊重すべきか

ServiceNowについて調べるとよく出てくる、OOTB（Out-of-the-Box）という言葉について、その意味と、なぜOOTBが重要なのかを解説します。OOTB（Out-of-theBox）とは何かServiceN...

servicenow-lab.com

2022.12.27

ServiceNowにおける開発資源とは？

上述のように、ServiceNowの開発では予め用意された設定箇所に値やコードを入力して行われるため、”ソースコード（ファイル）”や”実行可能ファイル”という概念はありません。その代わりに、Application File（アプリケーションファイル）およびCustomer Update（顧客アップデート）によって開発資源を管理します。

Application File（アプリケーションファイル）

ServiceNowで開発を行うと、開発資源を保持するApplication Fileテーブルに対してレコードが作成・更新・削除されます。

開発資源には様々な種類があり、種類ごとにApplication Fileを拡張（継承）した専用のテーブルが用意されています。上述の例だと、システムのデフォルトタイムゾーンを設定する場合はSystem Property、ユーザ名の表示形式を変更する場合はDictionary Entryというテーブルに格納されています。

Customer Update（顧客アップデート）

Customer Update（顧客アップデート）は、Application Fileの作成・更新・削除に合わせて作成・更新され、各Application Fileに加えられた顧客（ServiceNowを使っている企業）による最後に行われた変更内容を格納します。画面上での操作と、それに合わせてApplication File、Customer Updateがどのように作成・変更・削除されるかを下図に示します。

Customer Updateは顧客（ServiceNowを使っている企業）によって変更が行われた場合に作成されるため、ServiceNow社によって作られた標準機能については、初期状態でApplication Fileは存在しますが、それに変更を加えていなければ対応するCustomer Updateは存在しません。

また、ある設定を削除した場合、Application Fileも同時に削除されますが、Customer Updateとしては、”削除されたこと”が残ります。

ServiceNowにおける移送（デプロイ）とは？

開発資源の移送（デプロイ）方法には、開発資源をApplication Fileとして移送するApplication Repository（アプリケーションリポジトリ）と、Customer Updateとして移送するUpdate Set（更新セット）の2つがあります。

Application Reposiory（アプリケーションリポジトリ）

1つ目の方法は、開発資源をApplication Fileとして移送するための、Application Repository（アプリケーションリポジトリ）と呼ばれる方法です。

この方法では、Application FileをApplicationという単位にまとめた上で、開発インスタンスでServiceNowクラウドにあるApplication Repository（アプリケーションリポジトリ）にPublish（公開）し、本番インスタンスでそのApplicationをInstall（インストール）します。

Update Set（更新セット）- Customer Updateを移送する

2つ目の方法は、開発資源をCustomer Updateとして移送するための、Update Set（更新セット）と呼ばれる方法です。

この方法では、Customer UpdateをUpdate Set（更新セット）という単位にまとめた上で、Update Setをインスタンス間で授受します。

Update Setの授受には以下の2つの方法があります。

1. 本番インスタンス側で開発インスタンスの情報（URLや管理者権限を持つアカウントのID・パス）を設定し、Retrieve（取り込み）を行う

2. 開発インスタンスからUpdate SetをXMLファイルとしてエクスポートし、それを本番インスタンスにアップロードする

基本的にはApplication Repositoryを使う

歴史的な経緯としては、まずUpdate Setがあり、後からApplication Repositoryが後から登場しました。Application Repositoryが登場した当初は、不具合や機能の不足が多く、あまり使えませんでしたが、2022年12月Tokyoバージョン現在、Application Repositoryの方が優れている点が多いため、基本的にはこちらを使いましょう。

ただし、Application Repositoryを用いた移送は同じ企業に紐づくインスタンス間でしか行えないため、ServiceNow社の提供するトレーニングにおいて前提となる開発資源を開発者のPDI（個人開発インスタンス）に移送したり、自社インスタンスのApplicationに問題がありそれをPDIで検証したいといった場合はUpdate Setを使うことになるため、方法としては知っておくとよいです。

以上です。