本記事は筆者個人の検証・見解に基づくものであり、内容の正確性を保証するものではありません。実際の運用にあたっては公式ドキュメントおよび各組織のガイドラインをご確認ください。
はじめに
ServiceNowでは、開発したカスタマイズ内容を環境間で移送する手段として Update Set が広く使われています。Update Setは変更内容をXMLとしてキャプチャし、開発環境から本番環境へリリースする際の基本的な仕組みです。
ServiceNowのベストプラクティスでは、1つのUpdate Setに含める変更は小さく保つことが推奨されています。しかし実際の開発現場では、複数の機能追加や修正が重なり、Update Setの数が気づけば大量となってしまった、ということも多々あります。
複数のParent Update SetやBatch Update Setといった仕組みも用意されていますが、制約上、リリースを行う担当者の負荷は高いと思われます。
リリースのたびにこれらの作業を繰り返すことを考えると、手動運用には限界を感じてしまいます。
そこで注目したいのが、ServiceNow CICD APIです。本記事では、CICD APIの概要と実際の使い方について紹介していきます。
CICD APIとは？
CICD APIとは、アプリケーションの開発・テスト・本番デプロイまでの一連のフローを自動化するためのREST API群です。ServiceNowにおいては、2020年リリースのOrlando以降、CICD Spokeが標準搭載されています。
もともとはApplication Repositoryをベースとした仕組みでしたが、比較的新しいYokohamaリリースからはUpdate Set向けにも対応が拡張されており、より多くの現場で活用できるようになっているようです。1
CICD Spokeを使ってみる！
CICD Spokeにはいくつかのアクションが用意されており、Retrieveまで一括で実施するものや、Commitのみを実行するものなど、用途に応じて使い分けることができます。詳細についてはServiceNow公式Docsをご参照ください。
今回は以下の2つのアクションを使って、実際の動きを確認していきます。
実施イメージ
PDIを2台用意して下記の通りtest用の更新セットをRetriveとCommitまで実施してみます。
CICD REST API (com.glide.continuousdelivery) プラグインが必要になります。
1. 事前準備
1-1. prod側のsys_userにユーザーを追加
| 項目 | 設定値 |
|---|---|
| User ID | 任意のID |
| Use Name任意の名称 | |
| 付与ロール | sn_cicd.sys_ci_automation、teamdev_user |
| Password | 何でもよい |
| Web service access only | true（MFA認証回避のため） |
1-2. prod側のUpdate Source（sys_update_set_source）にレコード追加
1で作成したユーザの情報を追加します。
Typeは「Develophment」に設定しました。
URLはdevのものを指定します。
・レコード作成後に上記のSys_idを控えておくことを忘れずに。
・1-1でユーザーに「teamdev_user」を付与しておかないと、レコードが作成できません。
1-3. prod側のsys_userにユーザーを追加
| 項目 | 設定値 |
|---|---|
| User ID | 任意のID |
| Use Name | 任意の名称 |
| 付与ロール | sn_cicd.sys_ci_automation |
| Password | 何でもよい |
| Web service access only | true（MFA認証回避のため） |
1-4. Credentialにレコードを追加
dev側のCredentialにレコードを追加します。UserとPasswordは１－3で作成したユーザーの情報を追加します。
Credential Aliasは以下の赤枠を設定します。
（今回はBasic認証パターンです。）
1-5. dev側で更新セットを作成
その後、適当にテーブルを更新します。
今回はincidentテーブルにカラムを2個追加し、フォームレイアウトを変更にしました。
最後にStateを「Complete」にします。
1-6. dev、prodの環境で変更点を確認
・dev
cicd_test1、cicde_test2がカスタマイズした箇所になります。
・prod
cicd_test1、cicde_test2はまだありません。
2. 移送の確認
2-1. RetrieveのAction実行
devのWorkflow studioを開きActionの「Retrieve Update Set With Update Set Source ID」を選択し、「TEST」を実行します。
各パラメータは以下を設定してください。
| 項目 | 設定値 |
|---|---|
| Instance URL | 移送先のインスタンスURL |
| Credential Alias | 1-4で設定したもの |
| Update Set Source id | 1-2で控えたsys_id |
| Update Set id | 1-5で作成した更新セットのsys_id |
| Auto Preview | 今回はtrue（プレビューを自動で実施するかどうかのフラグです。） |
入力し終えたら、Run Testを実行します。
prodの環境で、移送元で作成した更新セットが登録されていることが確認できます。
Previewまで実施したら今度はコミットを実施してみます。
2-2. CommitのAction実行
devのWorkflow studioを開きActionの「Commit Retrieved Update Set」を選択し、「TEST」を実行します。
各パラメータは以下を設定してください。
| 項目 | 設定値 |
|---|---|
| Retrived Update Set id | 移送先の「sys_remote_update_set」にあるStateが「Previewd」かつ今回適用したい更新セットのsys_id （1-5で作成した更新セットのsys_idではありません。） |
| Credential Alias | 1-4で設定したもの |
| Instance URL | prodのインスタンスURL |
入力し終えたら、Run Testを実行します。
完了後、「State」が「Committed」になっていることを確認します。
2-3．適用状態を確認
prodのIncidentテーブルから任意のレコードを開き、適用状態を確認します。
・Commit前
・Commit後
きちんと移送されていることが確認できます。
3. 所感
今回はServiceNowのOOTB（Out of the Box）機能をそのまま利用しましたが、CICD APIはREST APIとしても提供されています。これをベースに独自のSubFlowやActionを作成することで、各現場の運用フローに合わせたカスタマイズも十分に可能です。
また、OOTBでも複数の標準部品が提供されているため、まずはそちらを活用するほうが、今後のアップグレードへの追従という観点からも望ましいでしょう。
ひとつ注意点として、コンフリクト（Confliction）への対応は人間の判断が必要になります。Update Setのリリースでは、コンフリクト発生時に作業を一時停止して手動で解消する手間が生じるため、完全な自動化とはいきません。この点においては、インストール後にSkipped Recordとして対処できるApplication Repositoryのほうが、CI/CDとの相性は良いかなと思いました。