本記事は、ServiceNow公式Docsや過去に実機調査した上で記載をしておりますが、個人的な解釈も付け加えております。ServiceNow公式見解とは異なる可能性もあります。
もし何か誤りがありましたら、ご指摘いただけると幸いです。
はじめに
ServiceNow上のアプリケーションを本番環境へリリースを行うためには、一般的にはテスト用環境で動作検証を行い、本番環境へリリースを行います。そのリリースの過程において、承認プロセス、リリースする資材の管理、方法など、アプリケーションのリリースはプラットフォームの運用、統制においても大事なファクターであると考えられます。
ServiceNowの機能としても、ReleaseOpsが展開され、Australiaでもアップデート情報が公開され、リリースの統制、効率化の促進が期待されます。
【参考１】https://www.youtube.com/watch?v=vtNvyqfWvas
リリースの方法には、更新セットとアプリケーションリポジトリの2種類のリリース方法があり、本記事では、今一度原点に立ち戻り、それぞれの特徴、メリット、デメリットをまとめてみました。
更新セットとアプリケーションリポジトリの比較
ServiceNowの運用において、リリースは単なる「移行作業」ではなく、プラットフォームの健全性を守る「統制の要」であり、開発成果物を本番環境へ届けるための主要なアプローチとして、思想の異なる2つの経路を理解し、使い分ける必要があります。
本記事では、【更新セット（Update Sets）】と【アプリケーションリポジトリ（App Repo）】のアーキテクチャ、メリット・デメリット、そしてその使い分けについて記載します。
1. 更新セット（Update Sets）の移送
更新セットは、開発者が明示的に「更新セット」を指定し、特定の設定変更（XMLファイル）を一つずつ積み込む、手動編成のアプローチです。
特徴とメカニズム
コンテナ化された変更: 開発者が特定の更新セットにレコードを記録します。
マニュアル・ルーティング: XMLファイルの手動エクスポート/インポートのPULL型移行により、各インスタンスへ順番に移送されます。
ファイルレベルの競合解決: 展開時（Preview時）にターゲットインスタンス内の最新バージョンと衝突した場合、管理者が手動で「Accept/Skip」を判断する必要があります。
| メリット | デメリット |
|---|---|
| グローバルスコープへの完全対応: プラットフォーム全体の基盤設定やレガシーなグローバルアプリの改修に不可欠。 | 依存関係と順序の属人化: 並行開発時にパッチの適用順序を誤るとシステムが破損するリスク（順序依存性）がある。 |
| 極めて高い柔軟性と細粒度: 特定のビジネスルール1つだけを抽出し、緊急パッチとして個別にリリース可能。 | 競合解決のオーバーヘッド: 大規模リリースにおいて、Preview時の競合（Collision）の確認と手動解決に膨大な工数を要する。 |
| 変更履歴の透明性: Customer Updateテーブルで「どのファイルが、いつ、誰によって変更されたか」を完全に追跡可能。 | 管理の煩雑化: 「Default」更新セットへの意図しない混入や、未完了の更新セットの放置など、運用ルールの徹底が難しい。 |
2. アプリケーションリポジトリ（App Repo）の移送
アプリケーションリポジトリは、個別のファイルではなく「アプリケーション全体」の状態をスナップショットのような形でバージョン（例: v1.0.1）管理し、リリースする手法です。
特徴とメカニズム
完全なカプセル化: バージョン単位で管理され、アプリの中身や過去の作成・変更分がすべて記録されます。
つまり、Scope用のDefault更新セットの中にリリース用資材がすべて格納され、それをリポジトリにアップロード（Publish）する仕組みです。更新セットリリースとは異なり、リリース用の更新セットを１ずつ作成するという運用が不要になります。
シームレスなデプロイ: インスタンス間でのファイルの移動やPreview作業は不要です。リポジトリからリリース対象環境への「Install/Update」ボタン一つで完結します。
アップロード時にVersion指定を行い、Publishします。その後、リリース先のインスタンスから対象アプリを「Install」します。
ただし、Install後にSkipped Recordのチェックとその対処は必須です。
CI/CDとの親和性: ServiceNowのAPIと連携し、自動テストや自動デプロイメントパイプラインの構築が比較的行いやすいです。（ただし、リリース作業に限った話で、ATFなど組み合わせ次第では複雑にはなります。）
| メリット | デメリット |
|---|---|
| コンフリクトフリーな展開: スコープによって名前空間が保護されているため、他アプリとの競合が発生しない。 | グローバル設定への非対応: 基本的にスコープド・アプリ専用。グローバルなシステムプロパティや基盤部分の変更には使用できない。 |
| バージョン管理の簡素化: アプリ全体を単一バージョンとして管理でき、Update Setよりシンプルとなる。 | 厳格なリリース順序やロールバック制約: リリース順序は直列で、並行作業は困難。また、複数バージョンをリリースした場合、部分的な切り戻しができず、厳しい順序制約が伴う。 |
| リリース作業の劇的な簡略化:複雑なXMLの移行手順書が不要になり、運用チームのデプロイ負荷が激減する。 | 個別ファイルのパッチ適用不可:単一のスクリプトだけを直したい場合でも、マイナーバージョンを上げてアプリ全体を再インストールする必要がある。 |
3. ロールバックの思想的違い
トラブル発生時の切り戻し（ロールバック）の振る舞いも根本から異なります。
【Update Set】の「Backout（取り消し）」
変更された個別のレコードを適用前の状態に戻す「Targeted（標的型）」のアプローチです。
リスク: 適用後に後続の更新セットが同じファイルを変更していた場合、依存関係が破壊される（Broken Dependencies）リスクがあります。
注意点: 削除更新が現在のセットに追加されます。更新セットをコミット、ロールバック、再適用すると、競合が発生し、プレビューエラーが発生します。ロールバック処理では、レコードレベルの更新と辞書への変更の両方が元に戻されます。ロールバックによって発生した変更の中には、データ損失につながるものもあります。
【App Repo】の「Rollback（ダウングレード）」
アプリケーション全体を過去のバージョンへ戻す「Versioned（バージョン型）」のアプローチです。
LIFO（Last-In, First-Out）制約: 地層構造のように積み重なるため、特定の過去バージョンへ直接ジャンプして戻すことはできません。最後にリリースしたものから順番にアンインストールしていく必要があります。
運用上の警告: まったく別の種類のアプリであっても同様の原則が適用されるため、複数の開発プロジェクトが同時並行で開発している場合は統制が困難です。
4. 管理方針：最適な使い分け（個人的見解）
開発要件に対し、どちらの手法を採用すべきかのガバナンス基準は以下の通りです。
対象アプリケーションがカスタムスコープのアプリ（Scoped App）か？
【App Repo】 を採用。
特に複数のアプリケーションのScopeがある場合、【Update Set】の場合、リリース作業が煩雑になりがちなので、シンプルな運用を行いたいのであれば【App Repo】に優位性があると思われます。
並行開発が必須か？
どちらも一長一短があるが、変更の粒度の細かさという点で【Update Set】に優位性があります。
理由としては、【App Repo】は更新セットのように変更分だけを切り出してリリースすることが仕組上できません。バグ対応と新規機能開発の同時並行が必要な場合に、リリース前に開発中の資材退避が必要になります。
5．運用中のリリース方法の併用や変更に関して
こちらはお勧めしません。
KBにも記載がある通りで、リリース対象の管理の仕組みなどが根本的に異なります。
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0715422
もし、実施する場合はそれぞれの仕組みを確実に理解したうえで、”相応の覚悟”をもって臨んでください。
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0786118
筆者の経験として【App Repo】から【Update Set】に変更した際、BackOut処理を行った際にエラーが発生したこともあります。
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0855315
6. リリースにおける注意事項
筆者が考えるリリースにおける鉄則を3つ記載します。
境界線の厳格化: Scoped Appの開発は原則すべてApp Repoに一本化する。同じアプリのリリースで更新セットを混用すると、後のアップグレードで重大な障害を引き起こす可能性があります。
Fix Forwardの原則 : ロールバックのリスクを避けるため、本番環境でのバグ発覚時は「切り戻し」ではなく、「修正版の次バージョン（パッチ）を即座にリリースする」運用を前提とします。
GlobalとScopedのリリース順序:主に【Update Set】で意識することですが、【App Repo】の運用でも意識する場合があります。例えば、業務上Global設定のリリースが発生する場合です。
Global設定（ポータルのテーマ変更等）とScoped Appの機能開発は管理設定が異なるため、リリースする資材の順番を意識することが必要です。リリース対象の関連性を確実に押さえておきましょう。
結論
「どちらの手法が優れているか」という二元論ではなく、対象の性質とライフサイクルに合わせて最適な方法を選択することが重要です。安易にロールバックがしやすいから【Update Set】、リリース管理の容易さから【App Repo】といった選別ではなく、各リリース方法を深く理解し、Fix Forwardを前提としたリリースガバナンスを構築しましょう。