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

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間：8分

    • DevOps アーティファクトパッケージとそれに関連するアーティファクトバージョンは、DevOps 変更にどのコミットが含まれるかを決定するために使用されます。

    コミットは、変更タイプに基づいて変更に含まれます。
    変更タイプ コミットが含まれる
    マニュアル 変更に含まれるパッケージのアーティファクトバージョンからのコミット。さらに、[data_type] 列が [計画] または [パイプライン実行] の場合に、変更参照レコード内のすべてのパイプライン実行のタスク実行からのコミットが含まれます。
    オートメーション
    • パッケージなし (Without package)：アーティファクトバージョンからのすべてのコミットが含まれます。アーティファクトバージョンは、パイプライン実行とそのパイプライン実行のタスク実行にリンクされているものです。
    • パッケージあり (With package)：変更の上流タスク実行のいずれかに本番展開ステップがある場合、最後に成功した本番展開パイプライン実行からのコミットが含まれます。複数のパイプライン実行に表示されるコミットは、1 回のみ一覧表示されます。本番展開ステップがアップストリームのタスク実行に存在しない場合は、パッケージのすべてのアーティファクトバージョンからのコミットが含まれます。
    • コミットを実行：前に指定したパッケージフローの有無にかかわらず、いずれからでもコミットがない場合、変更要求の上流タスク実行からの実行コミットが関連付けられます。
    最後の展開日以降に生成されたパッケージ内のアーティファクトバージョンに対するすべてのコミット (現在展開されているバージョンまで) が変更要求に含まれます。以前のメジャーバージョンは含まれません。
    注:
    パッチおよびホットフィックスのバージョンは除外されます。
    指定すると、セマンティックバージョンを使用して変更のコミットが決定されます。形式：MAJOR.MINOR.PATCH たとえば、セマンティック バージョン 2.0.1 は次のように読み取られます。
    • メジャーバージョン 2
    • マイナーバージョン 0
    • パッチ/ホットフィックス バージョン 1

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

    コミットのタイプ

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

    例: コミットとパッケージ

    この例は、次のもので構成されています。
    • 3 つのビルドパイプライン (A、B、C)
    • 4 つのパッケージを含む、変更管理下のリリースパイプライン (ABC):
      1. ビルドパイプライン A (メジャーバージョン 1)
      2. パイプライン A と B をビルドする (メジャーバージョン 1)
      3. パイプライン B と C をビルドする (メジャーバージョン 1)
      4. パイプライン A、B、C をビルドする (メジャーバージョン 1)
    表 : 1. パッケージ 1 (A 1.1.0)
    コミット ビルドパイプライン セマンティックバージョン パッケージに含まれるもの
    1 A 1.0.0 X
    2 A 1.0.1 --
    3 A 1.1.0 X
    注:
    コミット 2 (ビルド A、セマンティックバージョン 1.0.1) は、セマンティックバージョンの構文がパッチまたはホットフィックスを示しているため、パッケージには含まれません。
    表 : 2. パッケージ 2 (A 1.2.0、B 1.1.0)
    コミット ビルドパイプライン セマンティックバージョン パッケージに含まれるもの
    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) は、セマンティックバージョンの構文がパッチまたはホットフィックスを示しているため、含まれません。
    表 : 3. パッケージ 3 (B 1.2.0、C 1.0.0)
    コミット ビルドパイプライン セマンティックバージョン パッケージに含まれるもの
    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 が指定されていないため、含まれません。
    表 : 4. パッケージ 4 (A 1.4.0、B 1.3.0、C 1.2.0)
    コミット ビルドパイプライン セマンティックバージョン パッケージに含まれるもの
    17 A 1:40 X
    18 A 1:40 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 における変更の一部であるためです。

    例: コミット計算ロジック

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

    たとえば、2 つのパイプラインがあり、1 つはメイン ブランチに、もう 1 つはテスト ブランチにあるとします。実行シナリオ:

    • メインでコミット C0 を作成し、CI ビルドを実行しますが、アーティファクトバージョンは作成しません。
    • テストでコミット C1 を作成し、CI ビルドを実行しますが、アーティファクトバージョンは作成しません。
    • メインでコミット C2 を作成し、CI ビルドを実行すると、ビルドは失敗します。
    • メインで 2 つのコミット C3、C4 を作成し、CI ビルドを実行して、アーティファクトバージョン (v1.0) を作成します。
    予想される結果:アーティファクトバージョン (v1.0) は C0、C2、C3、C4 に関連付けられています。コミット C1 は別の分岐にあるため除外されます。
    ユースケースの続行：
    • メインでコミット C5 を 1 つ作成し、CI ビルドを実行しますが、アーティファクトバージョンは作成しません。
    • メインでコミット C6 を 1 つ作成し、CI ビルドを実行して、アーティファクトバージョン (v2.0) を作成します。
    予想される結果:作成された新しいアーティファクトバージョン (v2.0) は C5、C6 に関連付けられています。
    サマリー：
    • 特定のアーティファクトの最後のアーティファクトバージョンと現在のアーティファクトバージョンの間の、同じブランチでのパイプライン実行(成功と失敗)からのすべてのコミットが関連付けられます。
    • 指定されたアーティファクトの以前のアーティファクトバージョンが見つからない場合は、同じブランチ内のパイプライン実行からのすべてのコミットが関連付けられます。

    ユースケースの続行：

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

    期待する結果：
    • リリースは同じアーティファクトバージョン (v2.0) に関連付けられています。
    • 作成された変更要求には、アーティファクトバージョン (v2.0) が表示され、C0、C2、C3、C4、C5、C6 がコミットされます。
    サマリー：
    • メインブランチでビルドされた (以前のパッケージが本番に展開されていない) 両方のアーティファクトバージョン (v1.0、v2.0) からのコミットは変更要求に表示されますが、テストブランチでの実行からのコミットは表示されません。
    • 変更要求に表示されるコミットの数は、ツールの数と同じになります。
    ユースケースの続行：
    • テストブランチで 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 が表示されます。
    サマリー：
    • メインにビルドされた以前のアーティファクトバージョンからのコミットが以前のパッケージの本番に展開されていたため、変更要求には、メインブランチにビルドされた最新のアーティファクトバージョンからのコミットのみが表示されます。
    • 変更要求に表示されるコミットの数は、ツールの数と同じになります。
    • テストや展開などの他のステップタイプで本番展開と同じコミットロジックを使用するようにするには、[他のステップタイプが本番展開と同じロジックに従って変更 [sn_devops.commit_rel_change_step_type] プロパティのコミットを決定するかどうかを制御します。どのステップタイプ (展開やテストなど) が本番展開と同じコミットロジックをプロパティ値として使用するかを指定します。これらが設定されている場合、本番展開のコミットプロセスは関係スクリプトにも適用されます。