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

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：8分

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

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

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

    コミットのタイプ

    • 通常のコミット:追跡対象リポジトリ上のコミットは、変更要求に関連付けられます。
    • コミットを元に戻す:フィールド値を元に戻すがtrueのコミット。コミットを元に戻すと、ソースツリーでコミットが元に戻され、コミットが元に戻されます。両方のコミットが変更要求に関連付けられていません。
    • コミットの結合:フィールドの結合値が true のコミット。
      • マージコミット: ソースツリーは、ブランチへのコミットを経時的に追跡し、特別なマージコミットを行うことができます。このマージ コミットは、現在のブランチとマージ対象のブランチの両方で、最新の一般的なコミットの直後にある親コミットを結合します。コミットを結合すると、メイン ブランチに新しいコミットが追加されます。
      • スカッシュとマージ:マージ中にスカッシュすると、マージコミットを作成せずに、マージに一致する作業ツリーとインデックスの状態が生成されます。スカッシュとマージでは変更が保持されますが、個々のコミットが履歴から削除されます。結合値が 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 CMDB 360 テーブルの 1.0.0 X
    2 CMDB 360 テーブルの 1.0.1 --
    3 CMDB 360 テーブルの 1.1.0 X
    注:
    コミット 2 (ビルド A、セマンティックバージョン 1.0.1) は、セマンティックバージョンの構文がパッチまたはホットフィックスを示しているため、パッケージに含まれていません。
    表 : 2. パッケージ 2 (A 1.2.0、B 1.1.0)
    コミット ビルドパイプライン セマンティックバージョン パッケージに含まれるもの
    4 CMDB 360 テーブルの 1.1.1 --
    5 CMDB 360 テーブルの 1.2.0 X
    6 CMDB 360 テーブルの 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 CMDB 360 テーブルの 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
    注:
    パッケージがビルド A を指定していないため、コミット 11 (ビルド A、セマンティック バージョン 1.3.0) は含まれていません。
    表 : 4. パッケージ 4 (A 1.4.0、B 1.3.0、C 1.2.0)
    コミット ビルドパイプライン セマンティックバージョン パッケージに含まれるもの
    17 CMDB 360 テーブルの 1.4.0 X
    18 CMDB 360 テーブルの 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 における変更の一部であるためです。

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

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

    たとえば、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 が表示されます。
    サマリー：
    • main でビルドされた以前のアーティファクトバージョンからのコミットが以前のパッケージの Prod にデプロイされていたため、変更要求には、main ブランチでビルドされた最新のアーティファクトバージョンからのコミットのみが表示されます。
    • テスト上にビルドされたアーティファクトバージョンからのコミットは表示されません。
    • 変更要求に表示されるコミットの数は、ツールの数と同じです。