完了した更新セット履歴のソースコントロールへの移行

  • リリースバージョン: Xanadu
  • 更新日 2024年08月01日
  • 所要時間：5分

    • ソースコントロールにリンクすると、この機能により、アプリケーション開発者は完了した更新セット内の情報をソースコントロール履歴に移行することもできます。

    移行前

    更新セットを移行してみる前に、次の基準を満たしていることを確認してください。
    アプリケーションをソースコントロールにリンクすると、更新セットと顧客更新レコードが削除されます。ソースコントロールにリンクした後、アプリケーションに完了した更新セットがある場合は、下のダイアログボックスで選択を求められます。
    • [はい、更新セット履歴をコミットとして保持します] を選択した場合、更新セット履歴はソースコントロールのコミットとして保持されます。
    • [いいえ、更新セット履歴をコミットとして保持しません] を選択すると、コミットとして保持されません。
    選択したオプションに関係なく、[続行] を選択すると、[ソースコントロールにリンク] 操作が開始され、完了したすべての更新セットとすべての顧客更新レコードが削除されます。追加の更新セットを完了する必要がある場合、または続行しない場合は、[キャンセル] を選択します。更新セット履歴を選択するための選択を要求するダイアログボックス

    ソースコントロールにリンクしている、アプリケーションの更新を含む完了した更新セットごとに、更新セットの sys_update_xml レコードに基づいてコミットが自動的に生成されます。コミットは sys_recorded_at タイムスタンプ順に並べられます。グローバルアプリケーションの場合：アプリケーションに属し、完了したグローバル更新セットの一部である sys_update_xml レコードは、履歴コミットとしてキャプチャされます。

    [ソースコントロールにリンク] 操作が完了すると、最新のコミットがアプリケーション全体の状態になります。Git リポジトリでコミットの履歴を表示するか、 [ソースコントロール] メニューオプションをクリックして [履歴を表示] を選択します。更新は複数のコミットに分離されます。
    • 異なる更新セット間でファイルの更新が順序通りでない場合。
    • 更新セットに 1 つのファイルの複数の更新レコードが含まれている場合。

    1 つの更新セットに対するコミットは、複数のコミット ([過去のコミット 1]、[過去のコミット 2]...) に分割されて各更新を表します。これにより、各ファイルの更新の履歴が順序付けされます。

    警告:
    [過去のコミット] のプリフィックスが付いたコミットは、その履歴を表示するためだけに生成されます。これらのコミットがアプリケーションの安定したスナップショットを表すとは限らないため、開発プロセスではこれらをチェックアウトしないでください。

    最初のコミットまで、author_elective_update フォルダーは作成されません。つまり、最初のコミットでは、sys_choice ファイルなどのファイルの名前が変更され、update フォルダーから author_elective_update フォルダーに移動されている可能性があります。履歴コミットで更新セットから削除されたファイルは削除され、実際のコミットの場合とは異なり、author_elective_update フォルダーに移動されません。最初のコミット中に、完了した更新セットの一部として削除された DELETE sys_update_xml レコードに対しても削除ペイロードが作成されます。

    コミットメッセージの例：
    [Historical Commit 1] <Name of update set that this commit belongs to>
Description: <Description of update set that this commit belongs to>
Update Set was completed on / installed on <date>
Update Set was completed by <sys_user user_name > <sys_user email>
{
    sys_update_set レコードから追加される値 (下の「カスタマイズ」セクションを参照)
    }
{

    バッチ更新セットの情報 (下の「バッチ更新セット」セクションを参照)

    バッチ更新セット

    更新セットがバッチ更新セットの一部である場合、その情報は次の形式でコミットメッセージに追加されます (最大番号がバッチベース)。

    {
"1": {
"parent": "<name of parent update set>",
"description": "<description of parent update set>"
},
"2": {
"parent": " <name of parent 1’s parent update set> ",
"description": " <description of parent 1’s parent update set> "
}
}

    カスタマイズ

    コミットメッセージに含めるフィールドを追加するには、glide.source_control.historical_commit_fields プロパティを追加します。値は、ユーザーが sys_update_set XML フィールドから含めるフィールドの、カンマ区切りリストです。スペース、無効なフィールド名、またはスペルミスのあるフィールド名は無視されます。コミット担当者が更新セット履歴を保持することを選択した場合、このプロパティは、インスタンスからソースコントロールにリンクされているすべてのアプリケーションで使用されます。

    注:
    フィールドの値が別のテーブルまたは sys_id を参照する場合、フィールドの値のみが追加されます。たとえば、ユーザーの名前の代わりにそのユーザーの sys_id が追加されます。
    図 : 1. XML の例
    サンプル XML
    図 : 2. プロパティの値
    プロパティの値
    図 : 3. コミットメッセージの結果
    コミットメッセージに表示される結果