このモジュールでは、Studio と GitHub を使用して次のことを学習します。

• リポジトリを作成
• アプリケーションをソースコントロールにリンクする
• ソースコントロールからアプリケーションをインポートする
• アプリケーションの変更をソースコントロールにコミットする
• アプリケーションファイルの差異を比較する
• ブランチを作成する
• アプリケーションにアプリケーションテーブルのレコードを含める
• ブランチからコミットされた変更を結合する
• スタッシュを作成および管理する
• タグを作成する
• ソースコントロールで共同作業する
• 共同作業時の競合を回避および解決する

重要：この学習モジュールの内容は、Rome ServiceNow リリース用に最後に更新されました。

Event Tracker アプリケーションは、アプリケーション作成の基になる概念とプロセスを紹介し、デモンストレーションするために、この学習モジュール全体で使用されます。Event Tracker アプリケーションを構築することはありません。

実践的演習では、ウィッシュリストアプリケーションを開発します。

演習は、次の 3 つの方法で示されます。

• ナビゲーションペインの [演習] アイコン。
• ページ上部の [演習] アイコンと「演習」という単語。
• ページタイトルの「演習」または「課題」という単語。

ウィッシュリストアプリケーションを使用すると、ユーザーは必要なアイテムのリストを作成できます。

開発者は、ソースコントロールを使用してアプリケーションへの変更を追跡および管理します。ソースコントロールのソースは、アプリケーションを構成するファイルを参照します。ServiceNow では、アプリケーションファイルは、データベーステーブル、スクリプト、フロー、アクセス制御レコード、およびアプリケーションを構成するその他のファイルです。コントロールとは、アプリケーションファイルの管理です。

ソースコントロールには、次のような多くの利点があります。

• バックアップ：アプリケーションファイルを開発プラットフォームとは別に保存します。
• 変更の追跡：アプリケーションファイルの変更を表示し、過去のバージョンにアクセスします。
• バージョンコントロール：アプリケーションの以前のバージョンに戻します。
• 並列開発：開発者のチームは、1 つのアプリケーション上で同時に作業できます。
• コード構成：リリースされたアプリケーションとは別に進行中の作業を続行し、開発が完了したときに完了したアプリケーションファイルを結合します。

Git は、利用可能な最も一般的なソースコントロールプラットフォームの 1 つです。開発者は、Git のいくつかの関連用語に精通している必要があります。

• リポジトリ：ソースファイルが保存される場所
  • リモートリポジトリ：ソースファイルが保存および管理されるリモート Git リポジトリ
  • ローカルリポジトリ：開発者がアプリケーションファイルを作成および変更する Studio 内の作業リポジトリ
• 分岐：一意の名前を持つリポジトリ内のコード変更一式
• マスター：アプリケーションのメイン分岐またはトランク

他の用語については、トレーニングを通じて紹介していきます。

ServiceNow は Git ソースコントロールリポジトリをサポートしています。このモジュールでは、GitHub をアプリケーションとして使用して、Git リポジトリを管理および操作します。隅に GitHub Octocat ロゴが付いたボックスは、このモジュールの GitHub リモートリポジトリを表します。

アプリケーションは、ServiceNow 統合開発環境 (IDE) である Studio で作成します。開発者はローカルリポジトリを管理し、アプリケーションを Studio のリモートリポジトリにリンクできます。「アプリケーションを使用している開発者」は、このモジュールのローカルリポジトリを表します。

ソースコントロールと更新セット

準本番インスタンスでアプリケーションファイルを管理する従来の方法では、更新セットを使用します。開発者はアプリケーションを作成し、アプリケーションの変更を更新セットにキャプチャします。更新セットは、アプリケーションファイルをあるインスタンスから別のインスタンスに直接移動することも、XML ファイルとして移動することもできます。

ソースコントロールは、すべてのアプリケーション更新をリポジトリにロードし、以下のようなソースファイルの管理を追加します。

• アプリケーションファイルのリモートストレージ
• アプリケーション開発作業のブランチ
• 競合の回避と解決
• 変更の追跡
• XML ファイルやソースインスタンスの管理は不要

GitHub リポジトリには、アプリケーションに対してコミットされたアプリケーションファイルが保存されます。GitHub に空のリポジトリを作成し、アプリケーションをリポジトリにリンクしてソースコントロールの使用を開始します。アプリケーションとリポジトリの作成順序は重要ではありません。アプリケーションをリポジトリの前に作成することも、リポジトリをアプリケーションの前に作成することもできます。アプリケーションとリポジトリの両方が作成されると、アプリケーションをリポジトリにリンクできます。

GitHub でリポジトリを作成するには：

1. GitHub ホームページを開きます。

2. [リポジトリ] セクションで、[新規] ボタンをクリックします。

   

3. リポジトリのリポジトリ名と説明を入力します。リポジトリ名にスペースを含めることはできません。GitHub では、名前に含まれるすべてのスペースはハイフン (-) に置き換えられます。

   

4. [リポジトリを作成 (Create repository)] ボタンをクリックします。

開発者向けのヒント：アプリケーション名と一致するリポジトリ名を使用すると、アプリケーションのリポジトリを簡単に識別できます。

管理者または source_control ロールを持つユーザーは、Studio を使用して ServiceNow アプリケーションをリポジトリにリンクできます。

資格情報

ソースコントロールリポジトリへの接続では、資格情報ファイルを使用して、リポジトリに対して認証するための資格情報を安全に保存します。アカウントの資格情報は、複数のリポジトリで使用できます。

資格情報レコードを作成するには：

1. Application Navigator を使用して、[接続および資格情報] > [資格情報] を開きます。

2. [新規] ボタンをクリックします。

3. [作成する資格情報のタイプは？] リストで、[基本認証資格情報] を選択します。

4. [基本認証資格情報] レコードを構成します。

   
   名前：資格情報レコードを識別する名前。
   順序：複数の資格情報が存在する場合に資格情報が試行される順序。順序の値は、ソースコントロールには使用されません。
   ユーザー名：ソースコントロールリポジトリに対して認証するユーザー名。
   パスワード：ソースコントロールリポジトリに対して認証するパスワード。ソースコントロールリポジトリにマルチファクター認証が設定されている場合は、パスワードの代わりに個人用アクセストークンを使用します。
   アクティブ：これを選択して、資格情報を使用可能にします。
   資格情報エイリアス：資格情報を使用するデータ連携のリスト。資格情報エイリアスは、ソースコントロールには使用しません。

5. [送信] ボタンをクリックします。

アプリケーションのリンク

Studio を使用してアプリケーションをリポジトリにリンクするには：

1. GitHub のリポジトリページで、[URL をコピー] ボタン () をクリックしてリポジトリリンクをコピーします。

   

2. Studio でアプリケーションを開きます。

3. [ソースコントロール] メニューをクリックし、[ソースコントロールにリンク] メニューアイテムを選択します。

   

4. [ソースコントロールへのリンク] ダイアログを構成します。

   
   ネットワークプロトコル：ソースコントロールリポジトリへの接続に使用されるネットワークプロトコル。
   URL：ソースコントロールリポジトリの URL。
   資格情報：ソースコントロールリポジトリに対する認証のために作成された資格情報レコード。
   分岐：アプリケーションの作業を開始する分岐。ブランチが存在しない場合は、ブランチが作成されます。[マスター] を使用して、メインのソースコントロール分岐で開発します。分岐については、このモジュールの後半で説明します。
   MID Server 名：リポジトリへの接続に使用される MID Server の名前 (オプション)。
   デフォルトのメール：sys_user レコードで定義されたコミット担当者のメールアドレス。コミット担当者のメールアドレスが sys_user レコードに定義されていない場合、代替メールアドレスが生成されます。デフォルトのメールアドレスを入力し、すべての開発者からのコミットにデフォルトのメールアドレスを使用するには、このチェックボックスをオンにします (オプション)。
   コミットコメント：アプリケーションの初期コミットメッセージ。

5. [ソースコントロールへのリンク] ボタンをクリックします。

ソースコントロールにリンクされているアプリケーションの識別

Studio はアイコンを使用して、アプリケーションのソースコントロールステータスを表示します。アプリケーションを開く前に、[アプリケーションの選択] ダイアログのアイコンを使用して、ソースコントロールのステータスを確認します。Studio フッターのアイコンで、開いているアプリケーションの現在のステータスを確認します。

• ソースコントロールにリンクされていません：
• ソースコントロールにリンクされています：
• コミットを変更してソースコントロールにリンクされています：
• 利用可能なリモート変更によりソースコントロールにリンクされています：
• コミットの変更と利用可能なリモート変更によりソースコントロールにリンクされています：

Studio の [アプリケーションを選択] ダイアログには、各アプリケーションのステータスが表示されます。

Studio フッターは、アイコンを使用してソースコントロールのステータスを表示します。

admin または source_control ロールを持つユーザーは、Studio を使用してアプリケーションを非本番インスタンスにロードし、開発やテストをさらに進めることができます。

GitHub のリポジトリからアプリケーションをロードするには：

1. GitHub のリポジトリページから、[URL をコピー] ボタン () をクリックし、リポジトリリンクをコピーします。

2. [アプリケーションをインポート] ダイアログを開きます。

   1. Studio を開いていない場合は、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。
   2. Studio が既に開いている場合は、[ファイル] メニューを開き、[ソースコントロールからインポート] メニューアイテムを選択します。

3. [アプリケーションをインポート] ダイアログを設定します。

   
   ネットワークプロトコル：ソースコントロールリポジトリへの接続に使用されるネットワークプロトコル。
   URL：ソースコントロールリポジトリの URL。
   資格情報：ソースコントロールリポジトリに対する認証のために作成された資格情報レコード。
   分岐：アプリケーションの作業を開始する分岐。ブランチはリポジトリに存在する必要があります。リポジトリに分岐が存在しない場合は、マスターを使用します。
   MID Server 名：リポジトリへの接続に使用される MID Server の名前 (オプション)。
   デフォルトのメール：sys_user レコードで定義されたコミット担当者のメールアドレス。コミット担当者のメールアドレスが sys_user レコードに定義されていない場合、代替メールアドレスが生成されます。デフォルトのメールアドレスを入力し、すべての開発者からのコミットにデフォルトのメールアドレスを使用するには、このチェックボックスをオンにします (オプション)。

4. [インポート] ボタンをクリックします。

この演習では、Studio でアプリケーションを作成します。

注意：PDI が自動的に App Engine Studio を開く場合は、PDI にアクセスするために使用するユーザーロールを変更する必要があります。演習を完了するには、[管理者] ユーザーロールに切り替えます。

ウィッシュリストアプリケーションを作成

演習のこのセクションでは、Guided App Creator を使用して、簡単な Wish List アプリケーションを作成します。このアプリケーションを使用すると、ユーザーは必要なアイテムのリストを作成できます。この学習モジュールを進めながらアプリケーションを更新し、ソースコントロールを使用してアプリケーションファイルを管理します。

1. Guided App Creator を起動するには、Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。

2. [アプリケーションを選択] ダイアログで、[アプリケーションの作成] ボタンをクリックします。

3. これまで Guided App Creator を開いたことがない場合は、[ようこそ] 画面が表示されます。[始めましょう] ボタンをクリックします。

   注意：Microsoft Edge または Internet Explorer を使用している場合は、従来のアプリケーションクリエーターでしか作業できない可能性があります。Guided App Creator で作業するには、別のブラウザーを使用してください。重要なパフォーマンス上の問題があるため、Internet Explorer 11 から移行することをお勧めします。詳細については、HI の「KB0683275」を参照してください。

   

4. 新しいアプリケーションを構成します。

   名前：ウィッシュリスト (Wish List)
   説明：個人のウィッシュリストを作成 (Create personal wish lists)
   スコープ：(この値は、自動的に入力されます。デフォルト値を使用します。)

5. [作成] ボタンをクリックします。

6. アプリケーションの [ユーザー] ロールを作成します。

   1. [このアプリのいくつかのロールを作成しましょう] 画面で、[新しいロールを作成] リンクをクリックします。
   2. フライアウトで、新しいロールを設定します。
      新しいロール名：ユーザー
   3. フライアウトで [作成] ボタンをクリックします。

7. [続行] ボタンをクリックします。

8. [このアプリにどの形式を使用しますか？] 画面で、[クラシック] オプションを選択します。

   

9. [続行] ボタンをクリックします。

10. [データ] ペインの [このアプリにどのデータテーブルを使用しますか？] 画面で、[新しいテーブルの作成] ボタンをクリックします。

11. [ このアプリのテーブルを作成しましょう] 画面で、[テーブルを最初から作成] オプションを選択します。

12. [続行] ボタンをクリックします。

13. テーブルにフィールドを 2 つ追加します。

    1. [アイテム] フィールドをテーブルに追加します。

       1. [新しいフィールドを追加] リンクをクリックします。
       2. 新しいフィールドの構成：
          フィールドラベル：アイテム (Item)
          フィールド名：(この値は自動的に入力されます)
          フィールドタイプ：文字列
          文字数制限：125
       3. [アイテム] フィールドの必須化。
          1. [アイテム] フィールドの [展開] ボタン () をクリックします。
          2. [必須 (Mandatory)] オプションを選択します。

    2. [要求者 (Requester)] フィールドをテーブルに追加します。

       1. [新しいフィールドを追加] リンクをクリックします。
       2. 新しいフィールドの構成：
          フィールドラベル：要求者 (Requester)
          フィールド名：(この値は自動的に入力されます)
          フィールドタイプ：参照
          参照テーブル：User (sys_user)
       3. [要求者 (Requester)] フィールドの必須化。
          1. [要求者 (Requester)] フィールドの [展開] ボタン () をクリックします。
          2. [必須 (Mandatory)] オプションを選択します。

    3. [続行] ボタンをクリックします。

14. テーブルを構成します。

    テーブルラベル：ウィッシュアイテム (Wish Item)
    テーブル名：(この値は自動的に入力されます)

15. [続行] ボタンをクリックします。

16. [成功! [テーブルの準備が完了しました] 画面が表示されたら、[続行] ボタンをクリックします。

17. [このアプリにどのデータテーブルを使用しますか？] 画面で、[テーブルで完了しました] ボタンをクリックします。

18. [ それではアプリを設計しましょう！] という [設計] ペインの 画面で、[クラシック (Classic)] 形式の [開始] ボタンをクリックします。

19. [ 従来のアプリケーションのデザインをカスタマイズしましょう] 画面で [クラシック] アプリを構成します。ほとんどのフィールド値は事前入力されています。

    名前：ウィッシュリスト (Wish List)
    説明：個人ウィッシュリストアプリケーション (Personal wish list application)
    テーブルラベル：(ウィッシュアイテム) ((Wish Item))
    ロール：(x_<your_application_scope> .user)

20. [作成] ボタンをクリックします。

21. [お疲れ様でした。ここまでに設計したアプリは次のとおりです] 画面で、[アプリで完了しました] ボタンをクリックします。

22. [システム さん、お疲れ様でした。次に何を実行しますか?] 画面で、[Studio に移動] リンクをクリックします。

23. [アプリケーションを選択] ダイアログで、Wish List アプリケーションを選択します。

この演習では、GitHub でリポジトリを作成し、Wish List アプリケーションを Studio のリポジトリにリンクします。

GitHub でリポジトリを作成

演習のこの部分では、Wish List アプリケーションファイルを保存および管理するためのソースコントロールリポジトリを GitHub に作成します。

1. GitHub を開き、サインインします。

2. [リポジトリ] セクションで、[新規] ボタンをクリックします。

   

3. 新しいリポジトリを構成します。

   リポジトリ名：wish-list
   説明：ウィッシュリスト Now Platform アプリケーション

4. [リポジトリを作成 (Create repository)] ボタンをクリックします。

資格情報レコードを作成

ソースコントロールリポジトリへの接続に使用できる資格情報レコードを作成します。開発者サイトで他のトレーニング用に GitHub アカウントの資格情報レコードを作成した場合は、演習のこのセクションをスキップしてかまいません。

1. (Studio ではなく) ServiceNow のメインウィンドウで、Application Navigator を使用して、[接続 & 資格情報] > [資格情報] を開きます。

2. [新規] ボタンをクリックします。

3. [作成する資格情報のタイプは？] リストで、[基本認証資格情報] を選択します。

4. [基本認証資格情報] レコードを構成します。

   名前：GitHub 資格情報 (GitHub Credentials) - <お使いの GitHub ユーザー名>
   ユーザー名：<お使いの Github.com ユーザー名>
   パスワード：<お使いの GitHub パスワードまたは 2 要素認証の個人用アクセストークン>

   注意：2 要素認証を使用するように GitHub を構成した場合、個人アクセストークンの設定方法については、『 GitHub ガイド』の「 2 要素認証の使用 」セクションを参照してください。

5. [送信] ボタンをクリックします。

ウィッシュリストアプリケーションをソースコントロールにリンク

演習のこのセクションでは、新しい [wish-list] リポジトリを表示し、Wish List アプリケーションを新しいリポジトリにリンクして、コミットされたファイルを含むリポジトリを表示します。

1. リポジトリページの [コード] タブを確認します。GitHub にはリポジトリをセットアップするための指示が含まれていることに注意してください。現在、リポジトリにファイルは存在しません。

2. [クイックセットアップ] セクションで、[URL のコピー] ボタンをクリックします。

   

3. Studio で、Wish List アプリケーションが現在のアプリケーションであることを確認します。Wish List が、Studio フッターに表示されているアプリケーション名であるはずです。

   

   質問：アプリケーションがソースコントロールにリンクされていないことを確認するにはどうすればよいですか。
   
   回答：Studio フッターのアイコンにソースコントロールのステータスが表示されます。リポジトリにリンクする前のアイコンは、Wish List アプリケーションがソースコントロールに接続されていないことを示しています。

   
   
   

4. [ソースコントロール] メニューをクリックし、[ソースコントロールにリンク] メニューアイテムを選択します。

5. [ソースコントロールへのリンク] ダイアログで、ソースコントロールへのリンクを構成します。

   1. URL：<wish-list リポジトリ作成後にコピーした URL>

   2. 資格情報：GitHub 資格情報 (GitHub Credentials) - <お使いの GitHub ユーザー名>

   3. 分岐：マスター

   4. コミットコメント：SA：初期ウィッシュリストアプリケーションのコミット

      

6. [ソースコントロールへのリンク] ボタンをクリックします。

7. [ソースコントロールへのリンク] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

   

   質問：アプリケーションがソースコントロールにリンクされていることを確認するにはどうすればよいですか。
   
   回答：Studio フッターのアイコンにソースコントロールのステータスが表示されます。リポジトリにリンクした後のアイコンは、Wish List アプリケーションがソースコントロールに接続され、現在の分岐が [マスター] であることを示しています。

   
   

8. リモートリポジトリでアプリケーションを確認します。

   1. GitHub ブラウザーウィンドウで [wish-list] リポジトリに切り替えます。

   2. ブラウザーウィンドウを再ロードします。

   3. リモートリポジトリに Wish List アプリケーションファイルが含まれており、最初の [コミットコメント] が表示されていることを確認します。

      

アプリケーションの変更をリモートリポジトリに保存するには、Studio の [変更をコミット] メニューアイテムを使用します。

コミットプロセス中に、開発者はコミットする更新を選択します。コミットを完了するには、変更内容を説明するコミットコメントを入力します。

Studio で変更をコミットするには：

1. Studio で、コミットするアプリケーションを開きます。

2. [ソースコントロール] メニューを開き、[変更をコミット] メニューアイテムを選択します。

   

   注意：[変更をコミット] メニューアイテムが無効になっていても変更が加えられている場合は、Studio ブラウザーウィンドウを再ロードします。

3. [ソースコントロールにコミットするファイルを選択] ダイアログで、含める変更を選択します。

   • ユーザーの更新セットを選択すると、そのユーザーによる変更が表示されます。この例では、Fred Luddy が選択されており、リストには Fred Luddy の変更が表示されています。
   • [すべての更新セット] オプションを使用して、すべてのアプリケーションファイルの変更を確認します。
   • 各ユーザーの更新セットの横にある数字は、利用可能な変更の合計数に対してコミットするために選択された変更の数を示します。この例では、12 個の変更のうち 8 個が選択されています。Fred Luddy の 8 個の変更のうち 8 個すべてが選択され、システム管理者の 4 個の変更はどれも選択されていません。
   

4. [続行] ボタンをクリックします。

5. [ソースコントロールにコミットするファイルを確認] ダイアログで、選択したアプリケーションファイルの変更を確認し、[コミットコメント] フィールドにコミットに対するメッセージを入力します。

   

   開発者向けのヒント：組織やチームでコミットコメントの構造を標準化して、コミットコメントに必要な詳細が含まれるようにします。この例では、変更をコミットする開発者のイニシャルでコミットコメントを開始し、更新内容について説明しています。

6. [コミットファイル] ボタンをクリックします。

7. [変更をコミット] ダイアログにコミットが完了したことが示されたら、[閉じる] ボタンをクリックします。

GitHub サイトで、GitHub の [コード] タブを使用すると、最新のコミットが表示されます。コミット情報には、コミットコメントと、コミットを実行した ServiceNow ユーザーが含まれます。各ファイルの横にあるコミットコメントは、どのコミットがファイルの最新の更新かを示します。

Git に精通していますか？[変更をコミット] では、複数の Git 操作が実行されます。

1. ファイルを選択するとファイルがステージングされる
2. ステージングされたファイルはローカルリポジトリにコミットされる
3. ファイルはリモートリポジトリにプッシュされる

開発者は、アプリケーションファイルをリポジトリにコミットする前に、アプリケーションファイルのバージョンを比較できます。[ソースコントロールにコミットするファイルを選択] ダイアログで比較アイコン () をクリックして、バージョン間の違いを確認します。

比較内容は、新しいブラウザータブまたはウィンドウに表示されます。[比較してコミット] ウィンドウには、以下の設定が表示されます。

• コミットバージョン：リポジトリに最後にコミットされたアプリケーションファイルのバージョン。
• 現在のバージョン：リポジトリへのコミットが保留されているアプリケーションファイルの変更バージョン。

コミットバージョンと現在のバージョンの差異はハイライト表示されます。

[比較してコミット] ウィンドウには、[スクリプト] フィールドおよび [HTML] タイプフィールドの完全な内容は表示されません。比較の詳細がさらに続くフィールドには、詳細アイコン () が表示されます。このアイコンをクリックすると、そのフィールドのコミットバージョンと現在のバージョンの行ごとの比較が開きます。

行ごとの比較がダイアログで開きます。

• コミットバージョンには存在するが現在のバージョンには存在しないテキストには、赤色の点線で下線が引かれます。
  • この例では、8 行目と 9 行目のコメントが現在のバージョンで削除されました。
  • 11 行目の addErrorMessage() メソッドのテキストは、現在のバージョンで削除されました。
• 現在のバージョンには存在するがコミットバージョンには存在しないテキストには、緑色の点線で下線が引かれます。
  • 5 行目と 6 行目のコメントが現在のバージョンに追加されました。
  • 10 行目の addQuery() メソッドが現在のバージョンに追加されました。
• [コミットバージョン] のガターと [現在のバージョン] のガターには、異なるバージョンの行番号が表示されます。
• 中央のガターには、バージョン間の行の変化が示されます。変更されたテキスト行は青色でハイライト表示されます。変更されていない行にはハイライトはありません。テキストの行は、コミットバージョンと現在のバージョンの間で一致します。
  • この例では、3 行目が変更され、4 行目から 7 行目が現在のバージョンに追加されました。青色のハイライトがコミットバージョンの 3 行目のみから現在のバージョンの 3 行目～ 7 行目に拡大し、行が追加されたことが示されます。
  • コミットバージョン の 4 行目と 5 行目は変更されていませんが、現在のバージョンの 8 行目と 9 行目は変更されています。
  • コミットバージョンの 6 行目から 9 行目で、テキストが追加および削除されました。青色のハイライトは、現在のバージョンで、行が 10 行目から 12 行目にどのように移動したかを示しています。

スクロールロックの切り替えアイコンを使用して、スクリプトバージョンで画面外のコンテンツをみるためにスクロールする方法を設定します。

• ロック中： [コミットバージョン] と [現在のバージョン] が一緒にスクロールします。
• ロック解除済み： [コミットバージョン] と [現在のバージョン] が独立してスクロールします。

この演習では、Wish List アプリケーションを更新してから、変更をコミットします。変更をコミットする前に、アプリケーションファイル間の差異を比較します。

ウィッシュリストを更新

演習のこのセクションでは、[ウィッシュアイテム] テーブルにフィールドを追加して、ウィッシュリストの詳細情報を含めます。また、[アイテム] フィールドをテーブルの [表示] 値にします。

1. 前回の演習から Wish List アプリケーションが Studio で開かれていない場合は、ここで開きます。

2. Studio で、アプリケーションエクスプローラーを使用して、[データモデル] > [テーブル] > [ウィッシュアイテム] を開きます。

3. [列] タブで、[新規行を挿入...] リンクをダブルクリックします。

4. テーブル列を構成します。

   列ラベル：数量 (Quantity)
   タイプ：整数

5. このプロセスを繰り返して、URL フィールドを作成します。

   列ラベル：URL
   タイプ：URL

6. [アイテム] フィールドの [表示] 値を更新します。

   1. [アイテム] フィールドの [表示] 値 false をダブルクリックして、値を編集します。
   2. 値を true に設定します。
   3. [値を保存 (Save value)] ボタンをクリックします。

7. [更新] ボタンをクリックします。

質問：リモートリポジトリにコミットできるローカル変更があることをどのようにして知ることができますか。

回答：Studio フッターのアイコンにソースコントロールのステータスが表示されます。アプリケーションファイルを更新した後、アイコンは Wish List アプリケーションがソースコントロールに接続され、コミットするローカル更新があることを示します。

更新してもアイコンが変わらない場合は、Studio ブラウザーウィンドウを再ロードします。

変更をソースコントロールにコミット

演習のこのセクションでは、テーブルの更新をリポジトリにコミットします。コミットを完了する前に、いくつかのファイルの比較が表示されます。

1. [ソースコントロール] メニューを開き、[変更をコミット] メニューアイテムを選択します。

2. [ソースコントロールにコミットするファイルを選択 (Select files to commit to source control)] ダイアログで、リストされているアプリケーションファイルを確認します。

3. 更新されたアプリケーションファイルのバージョンを比較します。

   1. Wish Item.Item 辞書エントリの比較アイコン () をクリックします。

      質問：[アイテム] フィールドのどの構成値が変更されましたか。
      
      回答：[アイテム] フィールドで変更される値は [表示] 値のみです。前の値は未選択 (オフ) で、現在の値は選択 (オン) です。
      

   2. [比較してコミット] ウィンドウを閉じます。

4. 新しいアプリケーションファイルのバージョンを比較します。

   1. Wish Item.Quantity 辞書エントリの比較アイコン () をクリックします。

      質問：数量フィールドの比較結果はどうなりますか。
      
      回答：この更新前には [数量] フィールドは存在しません。[比較してコミット] ウィンドウには、[比較できません。コミットされたレコードが存在しません] と表示されます。
      

   2. [比較してコミット] ウィンドウを閉じます。

5. すべてのアプリケーションファイルが選択されていることを確認して、[続行] ボタンをクリックします。

   

6. [コミットコメント] <自分のイニシャル> を入力：[数量] フィールドと [URL] フィールドを追加し、[アイテム] フィールドを [ウィッシュアイテム] テーブルの表示値にしました。

7. [コミットファイル] ボタンをクリックします。

8. コミットが完了したら、[変更をコミット] ダイアログの [閉じる] ボタンをクリックします。

GitHub でコミットを検証

演習のこのセクションでは、GitHub でコミットを検証します。

1. GitHub で wish-list リポジトリを開きます。

2. 必要に応じて、リポジトリのブラウザーウィンドウを再ロードします。

3. 最新のコミットメッセージが、変更をコミットしたときに入力したコミットコメントと一致していることを確認します。

   

ブランチとは、一意の名前を持つリポジトリ内の一連のコード変更のことです。ブランチを作成すると、メインアプリケーションとは別にアプリケーションファイルを開発できます。

開発者は、ブランチを作成して次のことを行えます。

• 新しいコードを開発する
• アプリケーションの問題に対する修正を作成する
• 新しいアプリケーション機能を試す

どれも、現在動作しているアプリケーションに影響を与えることなく実行できます。

ブランチは、「ブランチの作成」から「プルして結合」まで、開発プロセスのライフサイクルをたどります。

• コミット：開発者は分岐に作業をコミットできます。各ブランチは複数のコミットを持つことができます。

  

• プル：開発がレビュー待ちの段階になったら、開発者は [プル要求] を作成して、変更が準備できたことを他のユーザーに知らせます。他の貢献者は、提案された変更をレビューして、レビューコメントを追加し、プル要求ディスカッションに貢献することができます。開発者は、プル要求にコミットを追加して、ディスカッションからのフィードバックに対処できます。開発者は GitHub でプル要求を作成します。プル要求は、あるブランチが他のブランチに接続も結合もされておらず、別のブランチを指しているように見えるアイコンを使用します。

  

• 結合：分岐での開発が完了してコミットされると、開発者は完了した分岐を上流の分岐に結合します。結合とは、変更をあるブランチから別のブランチに移動するプロセスです。上流ブランチは、プル要求ブランチの作成元のブランチです。開発者は GitHub でプル要求からブランチを結合します。

  

• 削除：分岐が結合された後、または分岐での作業を破棄する場合は、リポジトリから分岐を削除します。開発者は GitHub でブランチを削除します。GitHub は、結合されたブランチを「安全に削除できる」とマークします。

  

Studio を使用して、アプリケーションのブランチを作成します。アプリケーションは、1 つのインスタンスに 1 つのアクティブなブランチしか持てません。

Studio でブランチを作成するには：

1. Studio で、[ソースコントロール] メニューを開き、[分岐を作成] メニューアイテムを選択します。

2. [分岐を作成] ダイアログで、分岐名を入力し、[分岐を作成] ボタンをクリックします。

   

   注意：分岐名にスペースを含めることはできません。

3. [分岐を作成] ダイアログに分岐が作成されたことが示されたら、[閉じる] ボタンをクリックします。

   

ブランチの作成失敗

この例では、分岐名にスペースが含まれています。

ブランチが正常に作成されない場合は、失敗の詳細をお読みください。詳細を使用して、問題のトラブルシューティングと解決を行います。この例では、無効な名前が使用されたため、ブランチが正常に作成されませんでした。この例では、名前にスペースが含まれていました。

[戻る] ボタンをクリックして見直し、分岐名の値からスペースを削除して修正します。

GitHub でのブランチの表示

デフォルトでは、GitHub のリポジトリに、マスター分岐への最新コミットのファイルが一覧表示されます。

別の分岐を表示するには、[分岐] ボタンをクリックし、[分岐/タグの切り替え (Switch branches/tags)] フライアウトで別の分岐を選択します。この例では、[EventRegistration] 分岐が選択されてハイライト表示されています。

マスター分岐以外の分岐が選択されている場合、GitHub にはその分岐のマスター分岐との比較の様子が示されます。ブランチには、ブランチに含まれるファイルとコミットのみが表示されます。この例では、[EventRegistration] 分岐は、マスターの基になる 1 つのコミットです。

開発者は、インスタンス内でアプリケーションのアクティブなブランチに 1 つずつ対応できます。ブランチを切り替えると、アクティブなブランチが変更されます。

Studio でアクティブなブランチを変更するには：

1. 現在のブランチで行われた変更をコミットします。

2. [ソースコントロール] メニューを開き、[分岐の切り替え (Switch Branch)] メニューアイテムを選択します。

3. [分岐の切り替え (Switch Branch)] ダイアログで、アクティブにする分岐を選択し、[分岐の切り替え (Switch Branch)] ボタンをクリックします。

   

現在の分岐にコミットされていない変更がある場合、[分岐の切り替え (Switch Branch)] ダイアログに、既存の変更をスタッシュまたは破棄するかどうかの確認を求めるメッセージが表示されます。変更のスタッシュについては、このモジュールの後半で説明します。

この演習では、Wish List アプリケーションの分岐を作成して、現在のアプリケーションとは別に追加機能を開発します。

ウィッシュリストアプリケーションを確認

アプリケーションの開発を進める前に、Wish List アプリケーションの現在のステータスを確認します。

1. [ウィッシュアイテム] レコードを作成します。
   1. (Studio ではなく) ServiceNow ブラウザーのメインウィンドウでブラウザーウィンドウを再ロードして、Studio で作成されたアプリケーションを確認します。
   2. Application Navigator を使用して、[ウィッシュリスト] > [ウィッシュアイテム] > [新規作成] を開きます。
   3. [ウィッシュアイテム] を構成します。
      アイテム：Teddy Grahams
      要求者：Beth Anglin
      数量：5
   4. [送信] ボタンをクリックします。
2. 2 番目の [ウィッシュアイテム] レコードを作成します。
   1. リストヘッダーにある [新規] ボタンをクリックします。
   2. [ウィッシュアイテム] を構成します。
      アイテム：Teddy Grahams
      要求者：Amelia Caputo
      数量：12
   3. [送信] ボタンをクリックします。
3. [ウィッシュアイテム] のリストを確認します。リスト内のアイテムを簡単に区別できますか？

表示名を開発するためのブランチを作成

ウィッシュアイテムを区別しやすくするために、[表示名] フィールドを [ウィッシュアイテム] テーブルに追加します。[表示名] フィールドは、複数のフィールドを連結することによってウィッシュリストアイテムを一意に識別します。このモジュールの後半で、[表示名] フィールドの値を自動的に生成するビジネスルールを作成します。

1. 前回の演習から Wish List アプリケーションが Studio で開かれていない場合は、ここで開きます。

質問：Wish List アプリケーションのアクティブな分岐は何ですか。どうすればわかりますか。

回答：アクティブな分岐はマスター分岐です。アクティブな分岐は Studio フッターに表示されます。

2. Studio で [ソースコントロール] メニューを開き、[分岐を作成] を選択します。

3. 分岐を構成します。

   分岐名：表示名の追加 (Add Display Name)

4. [分岐を作成] ボタンをクリックします。

   質問：分岐を作成できますか。作成できるのはなぜですか？あるいは、作成できないのはなぜですか？
   
   回答：名前が有効でないため、分岐の作成に失敗しました。ブランチ名にスペースを含めることはできません。エラーメッセージは、ブランチ名が無効であることを示しています。

   
   
   

5. [戻る] ボタンをクリックします。

6. 分岐を構成します。

   分岐名：AddDisplayName

7. [分岐を作成] ボタンをクリックします。

8. [閉じる] ボタンをクリックします。

   質問：AddDisplayName 分岐が Studio のアクティブな分岐であることがどうしてわかりますか。
   
   回答：アクティブな分岐は Studio フッターに表示されます。ブランチが作成されたときにフッターが更新されなかった場合は、Studio ブラウザーウィンドウを再ロードします。

   
   
   

表示名フィールドを追加

演習のこのセクションでは、表示名フィールドを作成して、更新をリポジトリにコミットします。

1. Studio で、アプリケーションエクスプローラーを使用して、[フォームと UI (Forms & UI)] > [フォーム] > [ウィッシュアイテム [デフォルトビュー]] を開きます。

2. [フィールドタイプ] タブで、[文字列] フィールドタイプをフォームにドラッグします。

   

3. [フィールド文字列を編集 (Edit field String)] アイコンをクリックします。

4. フィールドのプロパティを構成します。

   ラベル：表示名 (Display name)
   名前：display_name
   最大長：300
   読み込み専用：選択済み (オン)
   

5. [プロパティ] フライアウトを閉じます。

6. [保存] ボタンをクリックします。

7. 新しいフィールドを表示します。

   1. ServiceNow ブラウザーのメインウィンドウ (Studio ではない) で、Application Navigator を使用して [ウィッシュリスト] > [ウィッシュアイテム] > [すべて] を開きます。

   2. 任意のレコードを開き、[表示名] がフォームに表示されることを確認します。

      

変更をコミットして GitHub で表示

フィールドを作成した状態で、リポジトリに変更をコミットし、GitHub で変更を表示します。

1. Studio で更新をコミットします。

   1. [ソースコントロール] メニューを開き、[変更をコミット] メニューアイテムを選択します。[変更をコミット] メニューアイテムを使用できない場合は、ブラウザーウィンドウをリフレッシュしてもう一度試します。
   2. [ソースコントロールにコミットするファイルを選択 (Select files to commit to sourc control)] ダイアログで、すべてのファイルを選択して [続行] ボタンをクリックします。
   3. コミットコメント <自分のイニシャル> を入力：表示名フィールドを追加。
   4. [コミットファイル] ボタンをクリックします。
   5. [変更をコミット] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

2. GitHub でブランチを表示します。

   1. GitHub ブラウザーウィンドウで [wish-list] リポジトリに切り替えます。

   2. リポジトリのブラウザーウィンドウを再ロードします。

      質問：GitHub で、報告された最新のコミットは何ですか。これは Studio で行った最新のコミットですか？作成できるのはなぜですか？あるいは、作成できないのはなぜですか？
      
      回答：デフォルトでは、表示される最新のコミットは、マスター分岐に対する前回のコミットです。ブランチのコミットを表示するには、ブランチ選択リストからブランチを選択する必要があります。

      
      
      

   3. ブランチを切り替えます。

      1. [分岐] 選択リストをクリックし、AddDisplayName 分岐を選択します。

         

      2. ブランチの詳細を確認します。

         質問：現在報告されている最新のコミットは何ですか。これは Studio で行った最新のコミットですか？作成できるのはなぜですか？あるいは、作成できないのはなぜですか？
         
         回答：表示される最新のコミットは、この演習の前半で分岐に対して行われたコミットです。
         

ブランチを切り替え

演習のこのセクションでは、Studio のマスター分岐に切り替えて、AddDisplayName 分岐で作成された [表示名] フィールドがマスター分岐に存在しないことを確認します。アプリケーションレコードが、ブランチの切り替えの影響を受けていないことを検証します。

1. Studio で、[ソースコントロール] メニューを開き、[分岐の切り替え (Switch Branch)] メニューアイテムを選択します。

2. [分岐の切り替え (Switch Branch)] ダイアログで、選択リストからマスター分岐を選択し、[分岐の切り替え (Switch Branch)] ボタンをクリックします。

3. [分岐の切り替え (Switch Branch)] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

4. Studio フッターでマスター分岐が選択されていることを確認します。それでも分岐に AddDisplayValue がアクティブとして表示される場合は、Studio ブラウザーウィンドウを再ロードします。

5. [表示名] フィールドがマスター分岐の一部ではないことを確認します。

   1. アプリケーションエクスプローラーを使用して、[データモデル] > [テーブル] > [ウィッシュアイテム] を開きます。

   2. [表示名] フィールドが [テーブルの列] リストに存在しないことを確認します。

      

6. [ウィッシュアイテム] テーブルのレコードを表示します。

   1. ServiceNow ブラウザーのメインウィンドウ (Studio ではない) で、Application Navigator を使用して [ウィッシュリスト] > [ウィッシュアイテム] > [すべて] を開きます。
   2. レコードを開き、フォームに [表示名] フィールドが含まれていないことを確認します。

ソースコントロールブランチのライフサイクルを覚えておいてください。

結合すると、変更が開発ブランチから別のブランチに移動します。結合プロセスはプル要求から始まります。

プル要求の作成

開発者は、ソースコントロールのブランチを結合する前に、プル要求を作成します。プル要求は、作業がレビュー準備完了であることを示します。開発者は GitHub でプル要求を作成します。

プル要求を作成するには：

1. GitHub で結合する分岐を選択し、[寄稿 (Contribute)] リンクをクリックします。フライアウトで、[プル要求を開く (Open pull request)] ボタンをクリックします。

   

2. [プル要求を開く (Open pull request)] ページで、変更されたファイルを確認します。

3. デフォルトでは、プル要求には最新のコミットの名前が付けられています。プル要求を説明する名前に変更します。この例では、名前は「結合する準備ができたユーザーエクスペリエンス更新」です。[プル要求を作成 (Create pull request)] ボタンをクリックします。

   

開発者は、[会話] タブでプル要求について話し合うことができます。アプリケーションに追加の変更が必要な場合、開発者は変更を加え、結合する前にブランチに変更をコミットすることができます。

プル要求の結合

開発が完了したら、GitHub でブランチを結合します。

ブランチを結合するには：

1. GitHub が競合をチェックした後、プル要求ウィンドウの [プル要求を結合] ボタンをクリックします。

   

2. [結合の確認 (Confirm merge)] ボタンをクリックします。

開発者は、ブランチを結合する前に、プル要求の競合に対処する必要があります。競合の解決については、このモジュールの後半で説明します。

プル要求と結合の詳細については、GitHub ヘルプサイトの「プルリクエストについて」を参照してください。

ブランチの削除

ブランチを結合した後、ブランチを削除してリポジトリのクラッターを取り除けます。プル要求が結合されたら、[分岐を削除] ボタンをクリックして、プル要求ページから分岐を削除します。

開発者がブランチでの作業を中止することにした場合にも、ブランチを削除することができます。分岐と分岐内の結合されていない作業を削除するには、GitHub で [分岐] タブを開きます。削除する分岐の [この分岐を削除 (Delete this branch)] () アイコンをクリックします。

リモートリポジトリが更新された場合、開発者はその変更内容を Studio で適用できます。アクティブなブランチに変更がロードされます。

リモート変更を適用するには：

1. 現在のブランチで行われた変更をコミットします。

2. [ソースコントロール] メニューを開き、[リモート変更を適用 (Apply Remote Changes)] メニューアイテムを選択します。

3. [リモート変更を適用 (Apply Remote Changes)] ダイアログで、[リモート変更を適用 (Apply Remote Changes)] ボタンをクリックします。

現在の分岐にコミットされていない変更がある場合、[リモート変更を適用 (Apply Remote Changes)] ダイアログにより、開発者は既存の変更をスタッシュするか破棄するかの選択が求められます。変更のスタッシュについては、このモジュールの後半で説明します。

この演習では、Wish List アプリケーションの分岐をマスター分岐に結合してから、GitHub で行った変更を Studio のローカルリポジトリに適用します。

ブランチを結合

分岐での作業が完了したら、その分岐をマスター分岐に結合します。演習のこのセクションでは、結合のプル要求を作成して結合を完了します。

1. GitHub で、[比較とプル要求 (Compare & pull request)] ボタンをクリックします。

2. [プル要求を開く (Open pull request)] ページで、変更されたファイルを確認します。

3. プル要求名を追加した表示名フィールドに設定します。

4. [プル要求を作成 (Create pull request)] ボタンをクリックします。

   

5. GitHub が競合をチェックした後、[プル要求を結合 (Merge pull request)] ボタンをクリックします。

   

6. [結合の確認 (Confirm merge)] ボタンをクリックします。

7. [分岐を削除 (Delete branch)] ボタンをクリックします。

リモート変更を適用

変更を GitHub のマスター分岐に結合したら、変更を反映するために Wish List アプリケーションを Studio で更新する必要があります。

1. Studio で [ソースコントロール] メニューを開き、[リモート変更を適用 (Apply Remote Changes)] メニューアイテムを選択します。
2. [リモート変更を適用 (Apply Remote Changes)] ダイアログで、[リモート変更を適用 (Apply Remote Changes)] ボタンをクリックします。
3. [リモート変更を適用 (Apply Remote Changes)] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。
4. 分岐の変更がマスター分岐に適用されたことを確認します。

   1. アプリケーションエクスプローラーを使用して、[データモデル] > [テーブル] > [ウィッシュアイテム] を開きます。

   2. [表示名] フィールドが [テーブルの列] リストに存在することを確認します。

      

スタッシュするとは、安全な場所に保管することです。ソースコントロールにスタッシュすると、アプリケーションのローカル変更が保存され、後で適用できます。ローカルの変更は、リモートリポジトリにコミットする必要はありません。変更をスタッシュすると、現在のアプリケーションからその変更が削除されて、後で開発者が適用したり削除したりできるように保管されます。

スタッシュを使用して次のことを行います。

• コミットされていないアプリケーションの変更を保存して後で再適用する
• アプリケーションの変更を保存して他のブランチに適用する
• ブランチから不要な変更を削除する

注意：スタッシュはリモートリポジトリに保存されません。アプリケーションが削除されたり、インスタンスがワイプされたりすると、スタッシュされた変更は失われます。

admin または source_control ロールを持つユーザーは、Studio を使用して変更をスタッシュできます。

1. Studio で [ソースコントロール] メニューを開き、[ローカル変更をスタッシュ] メニューアイテムを選択します。

   

2. [ローカル変更をスタッシュ] ダイアログで、スタッシュするアプリケーションファイルを確認します。

   

   開発者向けのヒント：アプリケーションファイルを選択的にスタッシュすることはできません。コミットされていないすべてのアプリケーションファイルの変更が、スタッシュに含まれます。アプリケーションをスタッシュに含めないようにするには、変更されたアプリケーションファイルをコミットしてからローカルの変更をスタッシュします。

3. スタッシュの説明を設定します。

4. [ローカル変更をスタッシュ] ボタンをクリックします。

5. [ローカル変更をスタッシュ] ダイアログが成功を報告したら、次を行います。

   • [閉じる] ボタンをクリックして、スタッシュの作成プロセスを終了します。
   • [スタッシュされた変更を適用] をクリックすると、スタッシュされた変更が自動的に再適用されます。

開発者向けのヒント：スタッシュの説明を追加して、スタッシュをレビューおよび管理するときにスタッシュに含まれる内容がわかるようにします。同僚も将来の自分も、それに感謝するでしょう。

開発者は、ブランチを切り替えたりリモート変更を適用したりしてアクティブなブランチを変更すると、コミットされていない変更をスタッシュして作業を保護するように求められます。

admin または source_control のロールを持つユーザーは、Studio を使用してスタッシュを管理できます。[スタッシュを管理] ダイアログで、開発者は現在の分岐にスタッシュを適用したり、スタッシュを削除したりすることができます。アプリケーションに複数のスタッシュがある場合、開発者はどのスタッシュを適用するかを確認する必要があります。

スタッシュの適用

スタッシュからアプリケーションに変更を追加するには、スタッシュを適用します。

1. Studio で、[ソースコントロール] メニューを開き、[スタッシュを管理] メニューアイテムを選択します。

   

   注意：[スタッシュを管理] メニューアイテムがアクティブでない場合、アプリケーションにはスタッシュがありません。

2. [スタッシュを管理] ダイアログで、適用するスタッシュの [適用] リンクをクリックします。

   

3. [スタッシュされた変更を適用] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

スタッシュした変更のコミット

ServiceNow は、ユーザー固有の更新セット内のスコープ対象のアプリケーションの変更を追跡します。スタッシュは、スタッシュ固有の個別の更新セットに保存されます。スタッシュが適用された後は、変更がコミットされるか、ユーザーの更新セットに取り込まれるまで、スタッシュのレコードを変更することはできません。

変更をコミットするには、スタッシュからコミットされた変更 (説明を参照) の変更をコミットします。スタッシュした変更がコミットされると、その変更はスタッシュレコードに存在しなくなり、スタッシュレコードを削除できます。

または、メッセージの最後にあるユーザーのリンクをクリックして、現在のユーザーの更新セット内のアプリケーションファイルを変更します。

スタッシュの削除

スタッシュを適用しても、スタッシュは削除されません。スタッシュに変更を適用してコミットした後、スタッシュを削除できます。不要なスタッシュを削除すると、スタッシュのリストを管理しやすくなります。

1. Studio で、[ソースコントロール] メニューを開き、[スタッシュを管理] メニューアイテムを選択します。

2. [スタッシュを管理] ダイアログで、適用するスタッシュの [削除] リンクをクリックします。

   

   注意：[スタッシュを管理] ダイアログには、スタッシュに含まれる内容の詳細は表示されません。日付と時刻を使用して、削除するスタッシュを特定します。

3. [スタッシュを削除] ボタンをクリックします。

この演習では、アプリケーションの変更をいくつか作成してスタッシュします。スタッシュを別のブランチに適用してから、スタッシュを削除します。

スタッシュした変更を使用するための準備

演習のこのセクションでは、Wish List アプリケーションのユーザーエクスペリエンスで作業するための分岐を作成します。この演習の後半で、このブランチに適用されるべきアプリケーションの変更を行います。

1. 前回の演習から Wish List アプリケーションが Studio で開かれていない場合は、ここで開きます。
2. 分岐を作成します。
   1. [ソースコントロール] メニューを開き、[分岐を作成] メニューアイテムを選択します。
   2. 分岐を構成します。
      分岐名：UserExperience
   3. [分岐を作成] ボタンをクリックします。
   4. [分岐を作成] ダイアログが成功を示したら、[閉じる] ボタンをクリックします。

ウィッシュリストアプリケーションを更新

演習のこのセクションでは、分岐を作成し、Wish List アプリケーションに機能を追加します。この機能は、新しいレコードの [要求者] フィールドのデフォルト値を、現在ログインしているユーザーに設定します。

1. AddPurchaseDetails と呼ばれる分岐を作成します。
2. クライアントスクリプトを作成します。
   1. [アプリケーションファイルを作成] リンクをクリックします。
   2. [フィルター... (Filter...)] フィールドに「クライアント」というテキストを入力するか、左側のペインのカテゴリから [クライアント開発 (Client Development)] を選択します。
   3. 中央ペインからファイルタイプとして [クライアントスクリプト] を選択し、[作成] ボタンをクリックします。
3. クライアントスクリプトを構成します。
   名前：ウィッシュアイテムセット要求者 (Wish Item Set Requester)
   テーブル：ウィッシュアイテム [x_<your_company_code> _wish_list_wish_item]
   UI タイプ：すべて
   タイプ：onLoad
   説明：新しいウィッシュアイテムレコードの要求者を現在ログインしているユーザーに設定します。ユーザーはフィールド値を変更できます。
4. [スクリプト] フィールドの内容を次のスクリプトに置き換えます。

function onLoad() { //Check if the form is for a new record. If it is a new record, //set the Requester value to the currently logged in user. if(g_form.isNewRecord()){ g_form.setValue('requester',g_user.userID); } }

5. [送信] ボタンをクリックします。
6. Studio の [ウィッシュアイテムセット要求者] の [クライアントスクリプト] タブを閉じます。

スタッシュを作成

大変です！！！作成したクライアントスクリプトが AddPurchaseDetails 分岐に含まれるためのものではないことに気づきました。このウィッシュアイテムセット要求者の [クライアントスクリプト] は、別の分岐に含まれるべきものです。演習のこのセクションでは、AddPurchaseDetails 分岐から、このウィッシュアイテムセット要求者の [クライアントスクリプト] を削除するためのスタッシュを作成します。この演習の次のセクションでは、適切なブランチにこのスタッシュを適用します。

1. [ソースコントロール] メニューを開き、[ローカル変更をスタッシュ] メニューアイテムを選択します。[ローカル変更をスタッシュ] メニューアイテムを使用できない場合は、Studio ブラウザーウィンドウを再ロードして、もう一度試します。
2. [スタッシュの説明] を [ウィッシュアイテムセット要求者クライアントスクリプト] に設定します。
3. [ローカル変更をスタッシュ] ボタンをクリックします。
4. [ローカル変更をスタッシュ] ダイアログが成功を報告したら、[閉じる] ボタンをク'リックします。

質問：ウィッシュアイテムセット要求者クライアントスクリプトは、アプリケーションエクスプローラーで使用できますか。

回答：スタッシュされたアプリケーションファイルは、現在の分岐から削除されています。ウィッシュアイテムセット要求者クライアントスクリプトは、AddPurchaseDetails 分岐で使用できなくなり、アプリケーションエクスプローラーに表示され,ません。ウィッシュアイテムセット要求者クライアントスクリプトがまだアプリケーションエクスプローラーで使用可能な場合は、Studio ブラウザーウィンドウを再ロードして、もう一度確認します。

スタッシュを適用

スタッシュした変更を別の作業ブランチに含める必要があるとします。演習のこのセクションでは、UserExperience 分岐に切り替えて、スタッシュを分岐に適用します。

1. UserExperience 分岐に切り替えます。

2. スタッシュを適用します。

   1. Studio の Wish List アプリケーションで、[ソースコントロール] メニューを開き、[スタッシュを管理] メニューアイテムを選択します。

   2. [スタッシュの管理] ダイアログの [ユーザーアクション] 列で、ウィッシュアイテムセット要求者クライアントスクリプトスタッシュの [適用] リンクをクリックします。

      

   3. [スタッシュされた変更を適用] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

3. アプリケーションエクスプローラーを使用して、[クライアント開発 (Client Development)] > [クライアントスクリプト] > [ウィッシュアイテムセット要求者] を開きます。

   質問：ウィッシュアイテムセット要求者クライアントスクリプトを更新できますか。
   
   回答：ウィッシュアイテムセット要求者クライアントスクリプトは、現在、スタッシュ更新セットで管理されています。さらに変更を加える前に、変更をコミットするか、ファイルの更新をシステム管理者の更新セットに移動する必要があります。
   

課題：更新をコミットする

スタッシュからリモートリポジトリに更新をコミットします。

課題ソリューション：

ソースコントロール メニューを使用して、変更をコミットします。[スタッシュからコミットされた変更] で [変更されたファイル] (説明参照) の更新を選択します。

[続行] ボタンをクリックし、[コメントコミット] を追加して、コミットプロセスを完了します。

スタッシュを削除

スタッシュされた更新が適用され、コミットされたため、そのスタッシュが不要になったと判断します。演習のこのセクションでは、スタッシュを削除します。

1. Studio で、[ソースコントロール] メニューを開き、[スタッシュを管理] メニューアイテムを選択します。
2. [スタッシュの管理] ダイアログの [ユーザーアクション] で、ウィッシュアイテムセット要求者クライアントスクリプトスタッシュの [削除] リンクをクリックします。
3. [確認] ダイアログで、[スタッシュを削除] ボタンをクリックします。
4. [スタッシュの管理] ダイアログで、[ダイアログを閉じる] ボタンをクリックします。

タグとは、アプリケーションの固定ファイルセットです。アプリケーションの開発において、特定のコミットに戻るためにタグを作成します。タグは通常、リリースの正確なバージョンを識別しますが、任意のコミットで既知の開発ポイントに戻るために使用できます。たとえば、V1.0 で欠陥が発見された場合、開発者は V1.0 タグから簡単に分岐を作成して欠陥を修正できます。

タグの作成

admin または source_control ロールを持つユーザーは、Studio を使用してタグを作成できます。タグを作成する前に、タグに含めるすべての変更をコミットします。

1. Studio で、[ソースコントロール] メニューを開き、[タグを作成] メニューアイテムを選択します。

2. [タグを作成] ダイアログで、[タグ名] を入力し、[タグを作成] ボタンをクリックします。

   

   注意：タグ名にスペースを含めることはできません。

3. [タグを作成] ダイアログに分岐が作成されたことが示されたら、[閉じる] ボタンをクリックします。

Studio は、タグ作成プロセスの一環として、タグをリモートリポジトリにプッシュします。GitHub でタグを表示するには、[コード] タブの下にある [タグ] タブをクリックします。

タグが正常に作成されない場合は、メッセージを読んでトラブルシューティングを行い、問題を解決してください。この例では、タグが正常に作成されておらず、「タグ名が無効です。別の名前をお試しください」というメッセージが表示されています。

[戻る] ボタンをクリックして見直し、[タグ名] を修正します。

タグの適用

タグを使用するには、Studio でタグからブランチを作成します。

リポジトリにタグがある場合、[分岐の作成] ダイアログには、タグを開始点として分岐を作成するための [タグから作成] フィールドが含まれます。

注意：開発者サイトでいずれかのトレーニングを完了している場合は、タグからの分岐の作成に慣れているはずです。開発者サイトのトレーニングでは、タグを使用して、既知のアプリケーションステータスでモジュールを開始できます。詳細については、『GitHub ガイド』を参照してください。

この演習では、Wish List アプリケーションで開発チェックポイントのタグを作成します。作成したタグは、このモジュールの後半で使用します。

課題：UserExperience ブランチを結合する

UserExperience 分岐のプル要求を GitHub で作成してから、分岐をマスター分岐に結合します。

課題ソリューション：

コミットおよびプル要求メッセージは異なる場合がありますが、UserExperience 分岐をマスター分岐に結合する手順は次のとおりです。

1. GitHub で UserExperience 分岐を選択し、[寄稿] リンクをクリックします。

2. フライアウトで、[プル要求を開く (Open pull request)] ボタンをクリックします。

   

3. プル要求に名前を付け、[プル要求を作成 (Create pull request)] ボタンをクリックします。

   

4. [プル要求を結合 (Merge pull request)] ボタンをクリックします。

5. [結合の確認 (Confirm merge)] ボタンをクリックします。

タグを作成

演習のこのセクションでは、Wish List アプリケーションに v0.1 タグを作成します。

1. 前回の演習から Wish List アプリケーションが Studio で開かれていない場合は、ここで開きます。
2. マスター分岐に切り替えます。
   1. [ソースコントロール] メニューを開き、[分岐の切り替え (Switch Branch)] メニューアイテムを選択します。
   2. [分岐の切り替え (Switch Branch)] ダイアログで、マスター分岐を選択します。
   3. [分岐の切り替え (Switch Branch)] ボタンをクリックします。
   4. [分岐の切り替え (Switch Branch)] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。
3. [ソースコントロール] メニューを開き、[タグを作成] メニューアイテムを選択します。
4. タグを構成します。
   タグ名：v0.1
5. [タグを作成] ボタンをクリックします。
6. [タグを作成] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

GitHub でタグを表示

GitHub で新しいタグを表示します。

1. github.com で wish-list リポジトリを開きます。

2. [コード] タブで、[タグ] リンクをクリックします。

   

3. タグの名前が「v0.1」であることを確認します。

これまで、このモジュールはソースコントロールを個別に使用することに重点を置いており、複数の開発者が同じアプリケーションで作業する場合にソースコントロールをどのように使用できるかについてはほとんど考慮してきませんでした。スコープ対象のアプリケーションでソースコントロールを使用すると、共同開発のメリットが得られます。

• ブランチを使用すると、開発者はリリースされたコードに影響を与えることなくコードを個別に処理できます。
• 修正に取り組む開発者のためにリリースにタグを付けることができ、別のリリースでアプリケーションを拡張します。
• プル要求では、分岐がマスター分岐に結合される前にコラボレーションが可能です。
• ソースコードはリモートに保存されるため、リポジトリにアクセスできる任意のインスタンスからアプリケーションにアクセスできます。
• アプリケーションは、Update Sets を管理することなく、ある非本番環境から別の非本番環境に移動できます。

共同作業には課題もあります。最も一般的な課題は競合です。2 人の開発者が同じファイルを変更した場合、どちらの変更が優先されるでしょうか？競合の解決については、このモジュールの後半で説明します。

Now Platform でのアプリケーション開発は、次の 3 つのシナリオのいずれかで行われます。

• 単一のインスタンス、単一の開発者
• 単一のインスタンス、複数の開発者
• 複数のインスタンス、複数の開発者

単一のインスタンス、単一の開発者

「単一のインスタンス、単一の開発者」シナリオでは、単一の開発者が Studio でアプリケーションを作成し、ソースコントロールを使用して変更を加え、インスタンスとは別にソースコードを保存します。開発者はブランチを使用して、完成したコードに影響を与えずに開発の変更内容をテストできます。

単一のインスタンス、複数の開発者

「単一のインスタンス、複数の開発者」シナリオでは、すべての開発者が単一のインスタンスのアプリケーションで作業します。各開発者が行った変更は、ユーザー固有の Update Sets で自動的に追跡されます。

「単一のインスタンス、複数の開発者」シナリオで作業する場合の考慮事項：

• ソースコントロールサインイン：シングルサインインでアプリケーションをリモートリポジトリに接続します。接続では、リポジトリで作業する権限を持つ任意のユーザーアカウントを使用できます。プル要求を作成、ディスカッション、または結合するためにリモートリポジトリで直接作業するユーザーは、ソースコントロールアプリケーションへの独自のサインインが必要です。
• コミット：コミットされた変更は、コミットのソースに基づいて異なる方法で記録されます。
  • Studio コミット：コミットされた変更は、変更をコミットした ServiceNow ユーザーアカウントに起因します。Fred Luddy が Amelia Caputo によって行われたアプリケーションの変更をコミットした場合、Fred は変更をコミットしたユーザーとして報告されます。開発者に自身で行った変更をリモートリポジトリにコミットさせるか、特定の開発者に変更をコミットするようにアサインすることを検討してください。
  • リモートリポジトリコミット：開発者はプル要求を作成し、リモートリポジトリに結合します。リモートリポジトリで実行されるすべてのコミットは、ソースコントロールユーザーに帰属します。
• 分岐：アプリケーションは、一度に 1 つのアクティブな分岐のみを持つことができます。アプリケーションで作業するすべての開発者は、同じブランチで作業する必要があります。

複数のインスタンス、複数の開発者

「複数のインスタンス、複数の開発者」シナリオでは、開発者は複数のインスタンスのアプリケーションで作業し、同じインスタンスで複数の開発者が作業することもあります。アプリケーションは、1 つのインスタンスで作成し、ソースコントロールにリンクし、他のすべてのインスタンスのソースコントロールからインポートする必要があります。

「複数のインスタンス、複数の開発者」シナリオで作業する場合の考慮事項：

• ソースコントロールサインイン：異なるサインインでアプリケーションをリモートリポジトリに接続できます。接続では、リポジトリで作業する権限を持つ任意のユーザーアカウントを使用できます。プル要求を作成、ディスカッション、または結合するためにリモートリポジトリで直接作業するユーザーは、ソースコントロールアプリケーションへの独自のサインインが必要です。
• コミット：「複数のインスタンス、複数の開発者」シナリオでのコミットに関する考慮事項は、「単一のインスタンス、複数の開発者」シナリオでの考慮事項と同じです。各インスタンスは、ユーザーが異なる場合があります。
• 分岐：単一のインスタンスのすべてのユーザーは同じ分岐で作業しますが、各インスタンスは別々の分岐で動作できます。分岐が開発される場所を区別するための分岐名に <instance_name>/ プリフィックスの使用を検討してください。この例では、各ブランチはインスタンス名をプリフィックスとして使用します。

注意：この例で使用されている個人開発者インスタンスはすべて架空のものです。アクティブなまたは廃止された、インスタンス名やブランチの類似性は、まったくの偶発的なものです。

単一のアプリケーションファイルが複数の開発者によって同時に更新されると、競合が発生します。競合は次の場合に発生します。

• 開発者がリモートリポジトリから変更を適用し、アプリケーションファイルにリモートバージョンとローカルバージョンの両方の変更がある場合。
• 開発者がスタッシュから変更を適用し、アプリケーションファイルにスタッシュバージョンと現行バージョンの両方の変更がある場合。

競合の回避

アプリケーションが単一のインスタンスで開発されている場合は、競合を回避できます。開発者がアプリケーションファイルを変更すると、その変更はユーザー固有の更新セットにキャプチャされます。別の開発者がファイルを開くと、そのファイルは編集用にロックされ読み取り専用になります。

フォームの上部にある警告メッセージは、レコードが他の場所で変更されたことを説明しています。この例では、Fred Luddy が [場所の検証] ビジネスルールを開き、Carol Coughlin がビジネスルールを既に更新していることを理解しています。

競合を避けるためにファイルが編集用にロックされている場合、開発者は次のことができます。

• 差異の表示：警告メッセージの [差異の表示] リンクをクリックして、アプリケーションファイルのコミットバージョンと現在のバージョンを比較します。
• <ユーザー名> の更新セットを使用：ユーザー固有の更新セットの名前をクリックして、アプリケーションファイルを更新した最初の開発者のユーザー固有の更新セット内のアプリケーションファイルを変更します。
• <ユーザー名> の現在の更新セットで続行：リンクをクリックして、現在のユーザーの更新セット内のファイルを編集します。
• 変更をコミット：[ソースコントロール] メニューの [変更をコミット] メニューアイテムを使用して、変更をリモートリポジトリに保存してから、さらに変更を加えます。

競合をローカルに解決

開発者がスタッシュした変更を適用するときは、検出された競合を解決してから、変更を適用する必要があります。

[スタッシュされた変更を適用] ダイアログには、競合を解決すべき競合ファイルが一覧表示されます。

競合の解決方法：

• アプリケーションファイルのアクションを選択し、[適用] リンクをクリックして、競合を解決済みとしてマークします。
• アプリケーションファイルを選択し、選択リストを使用して、選択したすべてのアプリケーションファイルにアクションを適用。

選択するオプションを決定する前に、[手動で適用] リンクを使用して、バージョン間の差異を確認します。スタッシュされたバージョンを現在のバージョンと比較します。

比較ウィンドウで競合を解決します。

• スタッシュを取得：スタッシュされたバージョンの値を使用し、現在のバージョンの変更をすべて無視します。
• 破棄されたスタッシュ：現在のバージョンの値を使用し、スタッシュされたバージョンの変更をすべて無視します。
• 結合を保存：スタッシュされたバージョンから変更を選択し、[右に移動] ボタン () を使用して現在のバージョンに移したら、結合された変更を保存します。

[手動で適用] リンクを使用して競合を解決し、ステータスが [競合解決済み] になったら、スタッシュの適用方法にそれ以上変更を加えることはできません。

スタッシュされた変更を適用する前に、アクションを特定するか、競合ごとにステータスを [競合解決済み] にする必要があります。

この演習では、1 人の開発者としてアプリケーションファイルを更新してから、別の開発者としてファイルを編集してみます。

タグからブランチを作成する

競合の回避と解決を実践するために、v0.1 タグから分岐を作成します。分岐を Fred Luddy として作成します。

1. 開いているすべての Studio ウィンドウを閉じます。

2. Fred Luddy の代理操作を行います。

   1. ServiceNow ブラウザーのメインウィンドウで、ServiceNow バナーのユーザー名をクリックしてユーザーメニューを開きます。[代理操作ユーザー] オプションを選択します。

      

   2. [ユーザーの検索] フィールドに「Fred」と入力します。

   3. ドロップダウンリストで、[fred.luddy] をクリックします。

      

   4. ServiceNow バナーの [ユーザーメニュー] を確認します。「Fred Luddy」になっているはずです。

      

3. Studio で Wish List アプリケーションを開きます。

   1. Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。
   2. [アプリケーションを選択] ダイアログで、Wish List アプリケーションを選択します。

4. 分岐を作成します。

   1. [ソースコントロール] メニューを開き、[分岐を作成] メニューアイテムを選択します。

   2. 分岐を構成します。

      分岐名：ConflictTesting
      タグから作成：v0.1
      

   3. [分岐を作成] ボタンをクリックします。

   4. [分岐を作成] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

アプリケーションファイルを作成

演習のこのセクションでは、次の 2 つのビジネスルールを作成します。

• 数量を検証
• 表示名を入力

1. [数量] がゼロより大きいことを確認するビジネスルールを作成します。

   1. [アプリケーションファイルを作成] リンクをクリックします。

   2. [フィルター... (Filter ...)] フィールドに「ビジネス」というテキストを入力するか、左側のペインのカテゴリから [サーバー開発 (Server Development)] を選択します。

   3. 中央のペインでファイルタイプとして [ビジネスルール] を選択し、[作成] ボタンを選択します。

   4. ビジネスルールを構成します。

      名前：数量を検証 (Validate Quantity)
      テーブル：ウィッシュアイテム [x_<your_company_code> _wish_list_wish_item]
      アクティブ：選択済み (オン)
      詳細：選択済み (オン)

   5. 実施時期フォームセクションを構成します。

      時期：以前
      挿入：選択済み (オン)
      更新：選択済み (オン)
      フィルター条件：[数量] [次の値以下] [0]

   6. アクションフォームセクションを構成します。

      アクションの中止：選択済み (オン)

   7. [送信] ボタンをクリックします。

2. [表示名] フィールドに入力するビジネスルールを作成します。

   1. [アプリケーションファイルを作成] リンクをクリックします。

   2. [フィルター... (Filter ...)] フィールドに「ビジネス」というテキストを入力するか、左側のペインのカテゴリから [サーバー開発 (Server Development)] を選択します。

   3. 中央のペインでファイルタイプとして [ビジネスルール] を選択し、[作成] ボタンを選択します。

   4. ビジネスルールを構成します。

      名前：表示名を入力 (Populate Display name)
      テーブル：ウィッシュアイテム [x_<your_company_code> _wish_list_wish_item]
      アクティブ：選択済み (オン)
      詳細：選択済み (オン)

   5. 実施時期フォームセクションを構成します。

      時期：以前
      挿入：選択済み (オン)
      更新：選択済み (オン)

   6. 詳細フォームセクションを構成します。

      条件：current.item.changes() || current.requester.changes() || current.operation() == 'insert'

   7. このスクリプトをコピーして、[スクリプト] フィールドの「 // Add your code here」というコメントの下に貼り付けます。

      // Calculate Display name value by listing the item followed by the // User in parentheses. For example, Pencils (Fred Luddy) current.display_name = current.item + " (" + current.requester.name + ")";

   8. [送信] ボタンをクリックします。

3. [ソースコントロールにコミットするファイルを選択] ダイアログが表示されますが、変更をコミットしません。

   1. [ソースコントロール] メニューを開き、[変更をコミット] メニューアイテムを選択します。[変更をコミット] メニューアイテムを使用できない場合は、まずブラウザーウィンドウを更新します。

      質問：新しいビジネスルールはどの更新セットで追跡されますか。
      
      回答：Fred がビジネスルールを作成したため、Fred Luddy の更新セットで両方のビジネスルールが追跡されます。

      
      
      

   2. [キャンセル] ボタンをクリックします。

4. Studio のブラウザータブを閉じます。

更新のためにアプリケーションファイルを移動する

Carol Coughlin が [数量を検証] ビジネスルールを更新しました。演習のこのセクションでは、Carol Coughlin の代理操作を行い、ビジネスルールを更新します。Fred は Carol にビジネスルールの作業が完了したことを伝えたので、Carol は自分の更新セットの変更を追跡するためにビジネスルールを移動することにしました。

1. Carol Coughlin の代理操作を行います。

   1. ServiceNow ブラウザーのメインウィンドウで、ServiceNow バナーのユーザーメニューを開きます。[代理操作ユーザー] オプションを選択します。
   2. [ユーザーの検索] フィールドに「 Carol 」と入力します。
   3. ドロップダウンリストで、[cardo.coughlin] をクリックします。
   4. ServiceNow バナーの [ユーザーメニュー] を確認します。これで、Carol Coughlin として操作できます。

2. Carol Coughlin の更新セットを構成するようにアプリケーションを設定します。

   注意：代理操作を行っているときは、Studio を開いてもユーザー固有の更新セットが作成されない場合があります。Studio を開く前にアプリケーションを選択して、更新セットが作成されていることを確認してください。

   1. ServiceNow バナーの設定アイコン () をクリックします。

   2. [システム設定] ダイアログで、[開発者] ペインを選択します。

   3. [アプリケーション] と [更新セット] の設定を確認します。Wish List アプリケーションが既に選択されている場合、[更新セット] の値は「Fred Luddy [ウィッシュリスト]」です。[更新セット] の値は、「Carol Coughlin [ウィッシュリスト]」にする必要があります。

      

   4. 稼働中のアプリケーションを構成します。

      アプリケーション：Wish List (Wish List アプリケーションが既に選択されている場合は、別のアプリケーションを選択してから、Wish List アプリケーションを選択します)
      更新セット：Carol Coughlin [ウィッシュリスト](自動的に設定されます)
      

   5. [システム設定] ダイアログを閉じます。

3. Studio で Wish List アプリケーションを開きます。

   1. Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。
   2. [アプリケーションを選択] ダイアログで、Wish List アプリケーションを選択します。

4. [数量を検証] ビジネスルールを更新します。

   1. アプリケーションエクスプローラーを使用して、[サーバー開発 (Server Development)] > [ビジネスルール] > [数量の検証] を開きます。

   2. フォームの上部にある警告メッセージをお読みください。

   3. 警告メッセージの「Carol Coughlin」リンクをクリックして、Carol の更新セットのビジネスルールを編集します。

      

   4. [アクション] フォームセクションで更新を行います。

      メッセージの追加：選択済み (オン)
      メッセージ：0 より大きい数量を追加してください。

5. [更新] ボタンをクリックします。

   質問：変更を適用した後、Carol は 「数量を検証」ビジネスルールを更新できますか。
   
   回答：Carol の 更新セットのビジネスルールが追跡されるようになりました。Carol は、別の更新セットの変更を明示的に選択しなくても更新を行うことができます。
   

現在の更新セットのアプリケーションファイルを更新する

Carol Coughlin が、「表示名を入力」ビジネスルールを更新しました。演習のこのセクションでは、Carol Coughlin としてビジネスルールを更新します。Fred が Carol に、後で追加したい変更があると伝えたので、Carol は Fred の更新セットに変更を加えることにしました。

1. 「表示名を入力」ビジネスルールを更新します。

   1. アプリケーションエクスプローラーを使用して、[サーバー開発 (Server Development)] > [ビジネスルール] > [表示名の入力] を開きます。

   2. フォームの上部にある警告メッセージをお読みください。

   3. 警告メッセージの「 Fred Luddy 」リンクをクリックして、Fred の更新セットのビジネスルールを編集します。

      

   4. [詳細] フォームセクションで更新を行います。

      1. 「|| current.quantity.changes()」を [条件] フィールドの値の最後に追加します。

      2. 以前に [スクリプト] フィールドに追加した JavaScript をこのスクリプトに置き換えます。

         // Calculate Display name value by listing the item followed by the // Quantity in parentheses, a dash, and then the Requester // For example, Comic Boxes (10) - Fred Luddy current.display_name = current.item + " (" + current.quantity + ") - " + current.requester.name;

         

2. [更新] ボタンをクリックします。

   質問：変更を適用した後、Carol は「表示名を入力」ビジネスルールを更新できますか。
   
   回答：ビジネスルールはまだ Fred Luddy の更新セットにあります。さらに変更を加えるには、Carol が Fred Luddy の更新セットで作業するか、ビジネスルールを Carol Coughlin の更新セットに移動する必要があります。
   

3. [ソースコントロールにコミットするファイルを選択] ダイアログが表示されますが、変更をコミットしません。

   1. [ソースコントロール] メニューを開き、[変更をコミット] メニューアイテムを選択します。[変更をコミット] メニューアイテムを使用できない場合は、まずブラウザーウィンドウを更新します。

      質問：新しいビジネスルールはどの更新セットで追跡されますか。
      
      回答：「数量を検証」ビジネスルールが Carol Coughlin の更新セットで追跡されるようになりました。更新セット名の横にある (+1) は、ファイルが元々別の更新セットで作成され、一度移動されたことを示します。「表示名を入力」ビジネスルールは、引き続き Fred Luddy の更新セットで追跡されます。

      

   2. [キャンセル] ボタンをクリックします。

4. Studio のブラウザータブを閉じます。

この演習では、アプリケーションファイル間にいくつかの競合を意図的に作成し、競合の解決プロセスを理解します。競合を作成するには、現在の変更をスタッシュします。すぐにスタッシュを適用して、アプリケーションファイルでの作業を続行します。いくつかの変更を行った後、スタッシュを適用して競合を解決します。

変更したアプリケーションファイルをスタッシュ

演習のこのセクションでは、前の演習で作成したビジネスルールをスタッシュし、すぐにスタッシュを適用します。

1. ServiceNow ブラウザーのメインウィンドウを再ロードします。Carol Coughlin の代理操作手続きをまだ行っていない場合は、Carol Coughlin の代理操作手続きを行ってください。
2. Studio で Wish List アプリケーションを開きます。
   1. Application Navigator を使用して [システムアプリケーション] > [Studio] を開きます。
   2. [アプリケーションを選択] ダイアログで、Wish List アプリケーションを選択します。
3. ローカル変更をスタッシュし、スタッシュを適用します。
   1. [ソースコントロール] メニューを開き、[ローカル変更をスタッシュ] メニューアイテムを選択します。
   2. [ローカル変更をスタッシュ] ダイアログで、[スタッシュの説明] を [元の入力とビジネスルールの検証 (Original Populate and Validate Business Rules)] に設定します。
   3. [ローカル変更をスタッシュ] ボタンをクリックします。
   4. [ローカル変更をスタッシュ] ダイアログが成功を報告したら、[スタッシュされた変更を適用] ボタンをクリックします。
   5. [閉じる] ボタンをクリックします。

アプリケーションファイルを変更

演習のこのセクションでは、Carol Coughlin として、ビジネスルールを変更します。

1. [数量を検証] ビジネスルールを編集します。

   1. アプリケーションエクスプローラーを使用して、[サーバー開発 (Server Development)] > [ビジネスルール] > [数量の検証] を開きます。

   2. 警告メッセージを読んで、Carol Coughlin リンクをクリックし、ビジネスルールを編集可能にします。

      

   3. 実行時期フォームセクションの値を変更します。

      注文： 50
      フィルター条件：[数量] [次の値未満] [1]

   4. [更新] ボタンをクリックします。

2. [表示名の入力] ビジネスルールを編集します。

   1. アプリケーションエクスプローラーを使用して、[サーバー開発 (Server Development)] > [ビジネスルール] > [表示名の入力] を開きます。

   2. 警告メッセージを読んで、Carol Coughlin リンクをクリックし、ビジネスルールを編集可能にします。

   3. <任意のテキスト> で [スクリプト] フィールドにコメントを追加します。

      

   4. [更新] ボタンをクリックします。

3. Studio の [ビジネスルール] タブを閉じます。

スタッシュされた変更を適用して競合を解決

スタッシュをブランチに適用するときは、スタッシュを適用する前に競合を解決する必要があります。演習のこのセクションでは、スタッシュを適用し、スタッシュと現在の変更の間の競合を解決します。

1. [ソースコントロール] メニューを開き、[スタッシュを管理] メニューアイテムを選択します。

2. [スタッシュを管理] ダイアログで、[元の入力とビジネスルールの検証 (Original Populate and Validate Business Rules)] スタッシュの [適用] リンクをクリックします。

3. スタッシュされた変更を破棄する前に、[数量を検証] ビジネスルールで差異を表示します。

   1. [スタッシュされた変更を適用] ダイアログで、「数量を検証」ビジネスルールの「手動で適用」リンクをクリックします。

      

   2. 比較をスクロールして差異を確認します。

   3. ダイアログの最上部にスクロールして戻り、[スタッシュを破棄] ボタンをクリックします。

4. 「表示名を入力」ビジネスルールの [アクション] を [スタッシュされた変更を取得] に設定します。

   

5. [スタッシュされた変更を適用] ボタンをクリックします。

6. [スタッシュされた変更を適用] ダイアログが成功を報告したら、[閉じる] ボタンをクリックします。

7. スタッシュされた変更が適用されていることを確認します。

   1. アプリケーションエクスプローラーを使用して、[サーバー開発 (Server Development)] > [ビジネスルール] > [数量の検証] を開きます。

   2. ビジネスルールの「実行するタイミング」セクションを確認します。

      質問：「数量の検証」ビジネスルールは、スタッシュされたバージョンまたは変更されたバージョンと一致しますか。
      
      回答：ビジネスルールは変更されたバージョンです。変更されたバージョンの [順序] フィールドの値は 50 で、[フィルター条件] はスタッシュから [数量] [次の値未満] [1] に設定されています。

   3. アプリケーションエクスプローラーを使用して、[サーバー開発 (Server Development)] > [ビジネスルール] > [表示名の入力] を開きます。

   4. 追加されたコメントが、[スクリプト] に存在しないことを確認します。

ソースコントロールに関する理解度を確認しましょう。以下の質問は、自分の進捗状況を評価するのに役立ちます。質問ごとに回答を決定し、質問の任意の場所をクリックして回答を表示します。

質問：次のソースコントロールプラットフォームのうち、Studio でのソースコントロールのデータ連携がサポートしているものはどれですか。

1. リビジョン管理システム (RCS)
2. 同時実行バージョンシステム (CVS)
3. ソースコードコントロールシステム (SCCS)
4. Git
5. サブバージョン

回答：正解は 4 の Git です。Studio は、GitHub や GitLab などの Git プラットフォームをサポートしています。

---

質問：アプリケーションの変更をリモートリポジトリに保存する方法を最もよく説明しているのは次のうちどれですか。

1. Studio の [ソースコントロール] メニューから [変更をコミット]
2. Studio の [ソースコントロール] メニューから [ソースコントロールにリンク]
3. GitHub の [プル要求を作成] ボタンをクリック
4. Studio の [ファイル] メニューからアプリケーションを保存
5. GitHub の [プル要求を開く] ボタンをクリック

回答：正解は 1 です。変更をコミットして、変更をリモートリポジトリにプッシュします。

---

質問：システム管理者 の変更のうち、コミットするために選択されたものはいくつありますか。

1. 3/9
2. 2/2
3. 1/6
4. 0/1
5. 1/9

回答：正解は 3. 1/6 です。合計 9 つの変更のうち 3 つがコミット対象として選択されています。Fred Luddy の両方の変更が選択されています。Carol Coughlin の 1 つの変更が選択されていません。

---

質問：Studio で開いているアプリケーションのソースコントロールの現在のステータスは次のうちどれですか。

1. ソースコントロールに接続されていない
2. ソースコントロールに接続されているが、更新はない
3. ソースコントロールに接続され、リモート更新が利用可能
4. ソースコントロールに接続され、コミットするローカル更新がある
5. 十分な情報が提供されていない

回答：正解は 4 です。Studio フッターには、現在のステータスを示すアイコンがあり、ソースコントロールに接続されていることがわかります。アイコンの上向きの矢印は、アプリケーションにコミットするローカル更新があることを示します。

---

質問：アプリケーションの現在アクティブな分岐は次のうちどれですか。

1. 数量を検証
2. WishSandbox
3. ウィッシュリスト
4. アプリケーションはソースコントロールに接続されていない
5. 十分な情報が提供されていない

回答：正解は 2 の WishSandbox です。Studio フッターには、アプリケーションのアクティブなブランチが表示されます。[数量を検証] は、編集用に開いているクライアントスクリプトです。Wish List は、Studio で開いているアプリケーションです。

---

質問：開発者が分岐を結合するプロセスを開始する方法を最もよく説明しているのは次のうちどれですか。複数の回答が正解の場合があります。

1. Studio で、[ソースコントロール] メニューを開き、[分岐を結合] メニューアイテムを選択します。
2. GitHub で結合する分岐を選択し、[プル要求] リンクをクリックします。
3. GitHub で結合する分岐を選択し、[新規結合要求] ボタンをクリックします。
4. Studio で、[ソースコントロール] メニューを開き、[新規プル要求] ボタンを選択します。
5. GitHub で、最近プッシュされた分岐の [比較とプル要求 (Compare & pull request)] ボタンを選択します。

回答：正解は 2 と 5 です。結合プロセスはプル要求から始まります。GitHub のブランチからプル要求を開始します。分岐が最近プッシュされた場合、GitHub には任意の分岐ビューからプル要求を開始するためのショートカットがあります。

---

質問：スタッシュについて最も的確に定義しているものは次のどれですか。

1. コミットされていないファイルのローカル更新セット
2. 口と鼻の間の顔の毛
3. アプリケーションの固定ファイルセット
4. コミットするために選択された固定ファイルセット
5. 結合するファイルのリモート更新セット

回答：正解は 1 の コミットされていないファイルのローカル更新セットです。顔の毛は、ムスタッシュ (口ひげ) で、スタッシュではありません。タグは、通常はリリースを表すアプリケーションの固定ファイルセットです。最終的な応答は架空のものです。

---

質問：Now Platform でのタグの使用方法を説明しているのは次のうちどれですか。

1. Studio で、[ソースコントロール] メニューを開き、[タグを管理] メニューアイテムを選択します。適用するタグの [適用] リンクをクリックします。
2. Studio で、[ソースコントロール] メニューを開き、[分岐を作成] メニューアイテムを選択します。ブランチの作成に使用するタグを選択します。
3. Studio で、[ソースコントロール] メニューを開き、[タグの切り替え] メニューアイテムを選択します。タグを選択します。
4. GitHub で、[リリース] タブを開きます。[タグ] タブをクリックします。[分岐に適用] ボタンをクリックし、タグを適用する分岐を選択します。
5. GitHub で、ブランチを選択します。[新規プル要求] ボタンをクリックします。ブランチにプルするタグを選択します。

回答：正解は 2 です。タグは、既知の開始点から開始するために使用できるアプリケーションのリリースです。タグからブランチを作成し、タグ付けされたリリース点からテストまたは開発を行います。最初の回答は、スタッシュがどのように適用されるかであり、タグという単語に置き換えられています。タグは GitHub で表示および削除できますが、Studio で作成および適用する必要があります。

---

質問：正誤問題？スタッシュを適用するときに競合を解決する唯一の方法は、「スタッシュされた変更の取得」か、「スタッシュされた変更の破棄」です。

回答：正解は誤りです。[手動で適用] リンクをクリックして差異を表示し、スタッシュから更新を選択的に適用して競合を解決します。

---

質問：複数のインスタンスを使用するように開発環境を構成する方法について、最もよく説明しているのは次のうちどれですか。

1. Studio を使用して各インスタンスでアプリケーションを作成し、アプリケーションを単一の Git リポジトリにリンクします。
2. 1 つのインスタンスでアプリケーションを作成して、ソースコントロールにリンクし、他のインスタンスからプル要求を開始します。
3. 1 つのインスタンスでアプリケーションを作成して、ソースコントロールにリンクし、他のすべてのインスタンスについてはソースコントロールからインポートします。
4. Git リポジトリを作成し、ソースコントロールからすべてのインスタンスにリポジトリをインポートします。
5. 各インスタンスからアプリケーションの更新セットをダウンロードし、Git リポジトリで更新セットを結合します。

回答：正解は 3 です。アプリケーションのスコープを初期化するには、単一のインスタンスでアプリケーションを作成する必要があります。アプリケーションがソースコントロールにリンクされた後、アプリケーションを他のインスタンスにインポートして分散開発することができます。

---

コアコンセプト：

注意：この学習モジュールは、このまとめで参照する Git プラットフォームとして GitHub を使用します。

• Now Platform アプリケーションでソースコントロールを使用して、次のことを行います。
  • インスタンス外のアプリケーションのバックアップ
  • 変更の追跡
  • バージョンの管理
  • 並行開発
  • コードを整理
• アプリケーションを Git ベースのリポジトリに接続します
  • 任意の Git プラットフォームでリモートリポジトリを作成
  • リモートリポジトリにアプリケーションファイルを保存
  • Studio のリモートリポジトリへのリンク
  • ソースコントロールからアプリケーションインポートして、異なるインスタンスのアプリケーション上で作業
• 変更されたアプリケーションファイルをコミットして、リモートリポジトリに作業を保存
  • アプリケーションファイルを選択的にコミット
  • アプリケーションファイルの変更を比較
• リリースされたコードに影響を与えずにアプリケーション機能を開発するためのブランチを作成する
• 分岐を結合して、完了した分岐をマスター分岐に適用
  • Git でプル要求を作成
  • Git でプル要求について議論
  • Git で結合を完
• ローカルで変更を次にスタッシュ：
  • コミットされていないアプリケーションの変更を保存して後で再適用する
  • アプリケーションの変更を保存して他のブランチに適用する
  • ブランチから不要な変更を削除する
• 将来適用する正しいスタッシュを見つけるためにスタッシュに名前を付ける
• アプリケーションのリリースされたバージョンを指すタグを作成
• ソースコントロールで共同作業する
• スタッシュやリモート変更の適用時に、更新間の競合を解決する