アプリの展開

アプリケーションをビルドして検証したら、アプリケーションを本番環境に移行する必要があります。アプリケーションは、アプリケーションリポジトリを介して、または Update Sets を使用して移動できます。本番環境に移行する前に、アプリケーションをテスト環境に展開する必要があります。

アプリケーションリポジトリ (App Repo)

アプリケーションをアプリリポジトリに公開すると、組織のすべての ServiceNow インスタンスでこのバージョンのアプリケーションを使用できるようになります。アプリリポジトリを使用して、アプリケーションを QA/テストインスタンス (テスト用) に展開し、最終的に本番 (Prod) インスタンスに展開します。

詳細については、「アプリケーションリポジトリへのアプリケーションの公開アプリケーションのインストール」を参照してください。

更新セット

アプリケーションリポジトリを使用してアプリケーションを展開できない場合は、代わりに更新セットを使用します。この図は、開発インスタンスからテストインスタンスにカスタマイズを展開するための更新セットのベストプラクティスライフサイクルを示しています。

品質の高い開発およびリリースプロセスを実現するためのプラクティス：

• カスタマイズは常にスタックの一番下から上に移動します。
  • ダウンスタックインスタンスがアップスタックインスタンスと一致するようにします。
  • スタックの途中で導入されたカスタマイズは、将来のダウンスタックからのプッシュで上書きされる可能性があります。
  • 一般的なシナリオは次のとおりです。
    • テストまたは本番環境での修正の必要性 – 常に開発から上にプッシュ
    • 選択リストなどの一般的な本番アドミンのカスタマイズ – 常に開発から上に更新をプッシュ
• 転送する前に、更新セットに含まれる更新を必ず確認してください。
  • 他の開発作業に関連する更新とテストに関連する更新を探します。
  • システムプロパティと統合エンドポイントの変更を監視します。例：すべてのメールをテストメールアカウントに送信する sys_properties の変更をプッシュする
  • 更新を削除するのではなく、「スクラップ」更新セットに更新を移動します。
• プッシュ後は必ずテストを行い、必要なすべてのカスタマイズがキャプチャされ、期待どおりに適用されていることを確認します。
• 複数の並行リリースがある状況では、開発チーム間のコミュニケーションと調整を確実に行います。
• カスタマイズを誤ってキャプチャして他のチームメンバーが移行する可能性があるため、開発インスタンスでの実験は避けてください。
• デフォルトの更新セットで開発をキャプチャしないでください。

更新セットの [説明] フィールドにすべてのユーザーストーリー番号と簡単な説明を一覧表示します。更新セットを展開するために必要なすべての手動の手順を含めます。

更新セットにキャプチャされない展開に必要な手動の手順の一般的な例をいくつか示します。

• プラグインのアクティブ化。
• 更新セットで追跡されないテーブルの転送 (通常は先頭が「x_」または「u_」)。
• テーブルのデータベースインデックスの作成。インデックスの作成は更新セットを介して追跡されず、手動で行う必要があります。

更新セットの管理

ストーリーまたは欠陥に取り組むときは、正しい更新セットが選択されていることを確認し、更新セットのレコードを毎日確認してください。

更新セット間で sys_update_xml レコードを手動で移動しないでください。唯一の例外は、レコードをデフォルトの更新セットに移動することです。

更新セットは構成情報を取得しますが、タスクまたはプロセスのデータは取得しません。たとえば、更新セットは、サービスカタログアイテムの定義と、変数や変数の選択などの関連する構成データを追跡します。ただし、テストで行われた注文 (要求、アイテム、カタログタスク) は、更新セットによって追跡されません。

更新セットの推奨事項と禁止事項に注意してください。

• 現在の更新セットから特定の sys_update_xml レコードを削除するには、レコードをデフォルトの更新セットに移動し、レコードをデフォルトの更新セットに移動する理由をレコードの sys_update_set.comments フィールドに入力します。
• 1 つの更新セットから別の更新セットにカスタマイズレコードを移動しないでください。
• 更新セットが新しい更新セットに正常に結合されている場合を除いて、更新セットを削除しないでください。
• あるインスタンスから別のインスタンスにデータを移動するには、常にデータ抽出またはインポートセットを使用します (更新セットは使用しません)。

更新セットのバッチ

更新セットのバッチにより、更新セットを一括でプレビューおよびコミットできます。

複数の更新セットがあると、問題が発生する場合があります。たとえば、更新セットを正しくない順序でコミットしたり、1 つまたは複数の更新セットを誤って除外してしまったりする可能性があります。完了した更新セットをバッチにグループ化することで、これらの問題を回避できます。

更新セットのバッチを階層に編成します。1 つの更新セットは、複数の子更新セットの親として機能することができます。与えられたセットは子と親の両方になれるので、複数レベルの階層を可能にします。階層の最上位にある 1 つの更新セットは、更新セットのベースとして機能します。

基本更新セットをプレビューまたはコミットすると、バッチ全体がプレビューまたはコミットされます。システムは処理の順序を決定し、変更が記録された日付とその逐次祖先に基づいて競合をチェックします。これら祖先は、更新セットの変更が行われた特定のインスタンスです。

更新セットのバッチ処理は、リリースに適用され、これにより、リリースの空の親更新セットが作成され、実際の更新セットが子としてリリースに含まれます。

更新セットのバッチ処理を使用する利点は次のとおりです。

• 個々の更新セットは、直前にリリースから削除できます。
• バッチ処理は、更新を削除できることを除いて、結合に似ています。
• バッチ更新セットは簡単に展開できます。親更新セットのみを処理する必要があります。

詳細については、「システムアップデートセット」を参照してください。

次に行うこと

アプリが展開されたので、アプリを改善および拡張する方法について考えます。次に行う処理を決定するためのいくつかの提案を以下に示します。

• アプリケーションを日常的に使用しているユーザーは、フィードバックの最良の提供元になります。希望する新機能や変更点について、ユーザーと話し合ってください。
• 追加の関連プロセスフローをフローデザイナーで自動化できるかどうかを判断します。
• 新しい IntegrationHub スポークを新しい統合に利用できるかどうかを判断します。