---
sourceDocument: Xanadu IT Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-service-management

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# DevOps変更要求に含まれるコミット

# DevOps変更要求に含まれるコミット {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：8分

DevOpsアーティファクトパッケージとそれに関連するアーティファクトバージョンは、DevOps変更に含まれるコミットを決定するために使用されます。  
コミットは、変更タイプに基づいて変更に含まれます。{#dev-ops-commits-release__table_myb_wnq_zzb__entry__2}

| 変更タイプ | コミットが含まれる |
|-|-|
| マニュアル | 変更に含まれるパッケージのアーティファクトバージョンからのコミット。さらに、\[data_type\] 列が \[計画\] または \[パイプライン実行\] の場合に、変更参照レコード内のすべてのパイプライン実行のタスク実行からのコミットが含まれます。 |
| 自動化 | * パッケージなし:アーティファクトバージョンからのすべてのコミットが含まれます。アーティファクトバージョンは、パイプライン実行とそのパイプライン実行のタスク実行にリンクされているものです。 * パッケージの場合:変更の上流タスク実行のいずれかに本番展開ステップがある場合、最後に成功した本番展開パイプライン実行からのコミットが含まれます。複数のパイプライン実行に表示されるコミットは、1 回のみ一覧表示されます。本番展開ステップがアップストリームのタスク実行に存在しない場合は、パッケージのすべてのアーティファクトバージョンからのコミットが含まれます。 * コミットの実行:前に指定したパッケージフローの有無にかかわらず、いずれからでもコミットがない場合、変更要求の上流タスク実行からの実行コミットが関連付けられます。 {#dev-ops-commits-release__ul_rrq_gnq_zzb} |
[ ]

{#dev-ops-commits-release__table_myb_wnq_zzb}  
前回の展開日以降に生成されたパッケージ内のアーティファクトバージョンに対するすべてのコミット (現在展開されているバージョンまで) が変更要求に含まれます。以前のメジャーバージョンは含まれません。  
注:  
パッチおよびホットフィックスのバージョンは除外されます。  
指定すると、セマンティックバージョンを使用して変更のコミットが決定されます。フォーマットは (MAJOR.マイナー。PATCH)。たとえば、セマンティック バージョン 2.0.1 は次のように読み取られます。

* メジャーバージョン 2
* マイナーバージョン 0
* パッチ/ホットフィックス バージョン 1
{#dev-ops-commits-release__ul_chw_zyz_rkb}

アーティファクトをビルドしなかったがコミットが関連付けられている、以前のバージョンと現在のアーティファクトバージョン間の失敗したタスク実行も、作成されたアーティファクトバージョンに関連付けられます。

## コミットのタイプ {#dev-ops-commits-release__section_g12_lmq_zzb}

* 通常のコミット:追跡されたリポジトリ上のコミットは、変更要求に関連付けられます。
* コミットを元に戻す (Revert commits):\[元に戻す\] フィールドの値が true になっているコミット。コミットを元に戻すと、コミットが元に戻され、ソースツリーでコミットが元に戻されます。どちらのコミットも変更要求に関連付けられていません。
* コミットの結合 (Merge commits):結合フィールドの値が true のコミット。
  * マージコミット:ソースツリーはブランチへのコミットを経時的に追跡し、特別なマージコミットを行うことができます。このマージコミットは、現在のブランチとマージされるブランチの両方で、最新の共通コミットの直後にある親コミットを結合します。Merge Commit は、メインブランチに新しいコミットを追加します。
  * スカッシュとマージ: マージ中にスカッシュすると、マージコミットを作成せずにマージに一致する作業ツリーとインデックスの状態が生成されます。スカッシュとマージは変更を保持しますが、個々のコミットを履歴から削除します。マージ値が true のコミットが 1 つあります。
  {#dev-ops-commits-release__ul_h2y_tmq_zzb}
{#dev-ops-commits-release__ul_nkx_nmq_zzb}

## 例: コミットとパッケージ {#dev-ops-commits-release__section_pd4_zhv_rkb}

この例は、次のもので構成されています。

* 3 つのビルドパイプライン (A、B、C)
* 4 つのパッケージを含む、変更管理下のリリースパイプライン (ABC):
  1. ビルド パイプライン A (メジャー バージョン 1)
  2. パイプライン A と B をビルド (メジャー バージョン 1)
  3. パイプライン B および C (メジャー バージョン 1) をビルドする
  4. パイプライン A、B、C をビルド (メジャー バージョン 1)
  {#dev-ops-commits-release__ol_nsy_bzw_rkb}
{#dev-ops-commits-release__ul_sny_xyw_rkb}  
{#dev-ops-commits-release__table_fk1_33v_rkb__entry__4}

| コミット | ビルドパイプライン | セマンティックバージョン | パッケージに含まれるもの |
|-|-|-|-|
| 1 | A | 1.0.0 | X |
| 2 | A | 1.0.1 | -- |
| 3 | A | 1.1.0 | X |
| 注: コミット 2 (ビルド A、セマンティック バージョン 1.0.1) は、セマンティック バージョンの構文がパッチまたはホット フィックスを示しているため、パッケージに含まれていません。 ||||
[表 : 1. パッケージ 1 (A 1.1.0)]

{#dev-ops-commits-release__table_fk1_33v_rkb}  
{#dev-ops-commits-release__table_in3_ljv_rkb__entry__4}

| コミット | ビルドパイプライン | セマンティックバージョン | パッケージに含まれるもの |
|-|-|-|-|
| 4 | A | 1.1.1 | -- |
| 5 | A | 1.2.0 | X |
| 6 | A | 1.2.0 | X |
| 7 | B | 1.0.0 | X |
| 8 | B | 1.0.0 | X |
| 9 | B | 1.1.0 | X |
| 10 | B | 1.1.0 | X |
| 注: コミット 4 (ビルド A、セマンティックバージョン 1.1.1) は、セマンティックバージョン構文がパッチまたはホットフィックスを示しているため、含まれません。 ||||
[表 : 2. パッケージ 2 (A 1.2.0、B 1.1.0)]

{#dev-ops-commits-release__table_in3_ljv_rkb}  
{#dev-ops-commits-release__table_v5g_dnv_rkb__entry__4}

| コミット | ビルドパイプライン | セマンティックバージョン | パッケージに含まれるもの |
|-|-|-|-|
| 11 | A | 1.3.0 | -- |
| 12 | B | 1.2.0 | X |
| 13 | B | 1.2.0 | X |
| 14 | C | 1.0.0 | X |
| 15 | C | 1.0.0 | X |
| 16 | C | 1.0.0 | X |
| 注: コミット 11 (ビルド A、セマンティック バージョン 1.3.0) は、パッケージでビルド A が指定されていないため、含まれません。 ||||
[表 : 3. パッケージ 3 (B 1.2.0、C 1.0.0)]

{#dev-ops-commits-release__table_v5g_dnv_rkb}  
{#dev-ops-commits-release__table_prg_xnv_rkb__entry__4}

| コミット | ビルドパイプライン | セマンティックバージョン | パッケージに含まれるもの |
|-|-|-|-|
| 17 | A | 1.4.0 | X |
| 18 | A | 1.4.0 | X |
| 19 | B | 1.3.0 | X |
| 20 | B | 1.3.0 | X |
| 21 | C | 1.1.0 | X |
| 22 | C | 1.1.0 | X |
| 23 | C | 1.2.0 | X |
| 24 | C | 1.2.0 | X |
| 注: コミット 11 もこのパッケージに含まれます。この理由は、最後のパッケージ (ビルド A のメジャーバージョン 1 を含む) であるパッケージ #2 が本番環境に展開されて以降、ビルド A のメジャーバージョン 1 における変更の一部であるためです。 ||||
[表 : 4. パッケージ 4 (A 1.4.0、B 1.3.0、C 1.2.0)]

{#dev-ops-commits-release__table_prg_xnv_rkb}

## 例:コミット計算ロジック {#dev-ops-commits-release__section_kxf_4z4_vbc}

アーティファクトバージョンに関連付けられたコミットを計算するロジックを使用したユースケース。分岐情報は、コミットが定義されるたびに含まれます。

たとえば、2 つのパイプラインがあり、1 つはメイン ブランチに、もう 1 つはテスト ブランチにあるとします。実行シナリオ:  
* メインでコミット C0 を作成し、CI ビルドを実行しますが、アーティファクトバージョンは作成しません。
* テストでコミット C1 を作成し、CI ビルドを実行しますが、アーティファクトバージョンは作成しません。
* メインでコミット C2 を作成し、CI ビルドを実行すると、ビルドは失敗します。
* メインで 2 つのコミット C3、C4 を作成し、CI ビルドを実行して、アーティファクトバージョン (v1.0) を作成します。
{#dev-ops-commits-release__ul_qxh_41p_vbc}予想される結果:アーティファクトバージョン (v1.0) は C0、C2、C3、C4 に関連付けられています。コミット C1 は別の分岐にあるため除外されます。  
ユースケースの続行:

* メインで 1 つのコミット C5 を作成し、CI ビルドを実行しますが、アーティファクトバージョンは作成しません。
* メインで 1 つのコミット C6 を作成し、CI ビルドを実行して、アーティファクトバージョン (v2.0) を作成します。
{#dev-ops-commits-release__ul_glf_gbp_vbc}予想される結果:作成された新しいアーティファクトバージョン (v2.0) は C5、C6 に関連付けられています。  
サマリー：

* 特定のアーティファクトの最後のアーティファクトバージョンと現在のアーティファクトバージョンの間の、同じブランチでのパイプライン実行(成功と失敗)からのすべてのコミットが関連付けられます。
* 指定されたアーティファクトの以前のアーティファクトバージョンが見つからない場合は、同じブランチ内のパイプライン実行からのすべてのコミットが関連付けられます。
{#dev-ops-commits-release__ul_ejh_4bp_vbc}

ユースケースの続行:

前のステップのアーティファクトバージョンでリリースを作成し、ステップタイプ = 製品展開の CD パイプラインを用意します。  
期待される結果:

* リリースは同じアーティファクトバージョン (v2.0) に関連付けられています。
* 作成された変更要求には、アーティファクトバージョン (v2.0) が表示され、C0、C2、C3、C4、C5、C6 がコミットされます。
{#dev-ops-commits-release__ul_nxx_bjp_vbc}  
サマリー：

* メインブランチでビルドされた (以前のパッケージが本番に展開されていない) 両方のアーティファクトバージョン (v1.0、v2.0) からのコミットは変更要求に表示されますが、テストブランチでの実行からのコミットは表示されません。
* 変更要求に表示されるコミットの数は、ツールの数と同じになります。
{#dev-ops-commits-release__ul_vlv_4jp_vbc}  
ユースケースの続行:

* テストブランチで 2 つのコミット C7、C8 を作成し、CI ビルドを実行してアーティファクトバージョンを作成します。予想される結果:アーティファクトバージョン (v3.0) は C1、C7、C8 に関連付けられています。

* メインブランチで 2 つのコミット C9、C10 を作成し、CI ビルドを実行してアーティファクトバージョンを作成します。予想される結果:アーティファクトバージョン (v4.0) は C9、C10 に関連付けられています。

* 前のステップ (v4.0) のアーティファクトバージョンでリリースを作成し、ステップタイプ = 製品展開の CD パイプラインを用意します。  
  期待される結果:
  * リリースはアーティファクトバージョン (v4.0) に関連付けられています。
  * 作成された変更要求には、アーティファクトバージョン (v4.0) が表示され、C9、C10 がコミットされます。
  {#dev-ops-commits-release__ul_ylc_ykp_vbc}
{#dev-ops-commits-release__ul_df1_pkp_vbc}  
サマリー：

* メインにビルドされた以前のアーティファクトバージョンからのコミットが以前のパッケージの本番に展開されていたため、変更要求には、メインブランチにビルドされた最新のアーティファクトバージョンからのコミットのみが表示されます。
* テストでビルドされたアーティファクトバージョンからのコミットは表示されません。
* 変更要求に表示されるコミットの数は、ツールの数と同じになります。
{#dev-ops-commits-release__ul_wg2_flp_vbc}