翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 完全な CI/CD プロセスの違い
CI/CD パイプラインは最新の*トランクベースのワークフロー*を使用します。このワークフローでは、開発者は小規模かつ頻繁な更新をメインブランチ (または*トランク*) にマージし、そのブランチが CI/CD パイプラインの CD 部分を通じてビルドおよびテストされます。このワークフローは、開発ブランチとリリースブランチがリリーススケジュールによって分離されている *Gitflow ワークフロー*に取って代わりました。多くの組織では、Gitflow は依然としてバージョン管理およびデプロイの一般的な方法です。しかし、これは現在ではレガシーと見なされており、CI/CD パイプラインに統合するのは困難な場合があります。
多くの組織では、Gitflow ワークフローからトランクベースのワークフローへの移行は不完全であり、その結果、途中のどこかで行き詰まって CI/CD への完全な移行を実現できずにいます。どういうわけか、これらのパイプラインはレガシーワークフローの一部の名残にしがみつき、過去と現在の間の移行状態で行き詰まってしまいます。Git ワークフローにおける違いを確認し、そのうえで、レガシーワークフローを使用することが以下にどのような影響を与えるかを説明します。
+ [環境整合性](environment-integrity.md)
+ [リリース](releases.md)
+ [セキュリティ](security.md)
最新の設定においてレガシー Git ワークフローの名残を特定しやすくするために、[Gitflow](#gitflow-approach) を最新の[トランクベース](#trunk-based-approach)のアプローチと比較してみましょう。
## Gitflow アプローチ
次の図は、Gitflow ワークフローを示しています。Gitflow のアプローチでは、複数のブランチを使用して複数の異なるバージョンのコードを同時に追跡します。開発者が現在のバージョンのコードに対して作業を続けている間に、将来のある時点でのアプリケーションの更新のリリースをスケジュールします。トランクベースのリポジトリでは機能フラグを使用することでこれを実現できますが、Gitflow にはデフォルトで組み込まれています。
Gitflow アプローチの結果の 1 つとして、アプリケーション環境が通常は同期していない状態になります。標準的な Gitflow の実装では、開発環境はコードの現在の状態を反映する一方で、本番前環境および本番環境は、最新のリリース時点のコードベースの状態で固定されたままになります。
これにより、本番環境で欠陥が発生した場合に事態が複雑になります。なぜなら、開発者が作業しているコードベースには未リリースの機能が含まれており、それを公開せずに本番環境にマージすることはできないからです。Gitflow がこの状況に対処する方法は、ホットフィックスを使用することです。ホットフィックスブランチはリリースブランチから作成され、その後、上位環境に直接デプロイされます。その後、コードを最新の状態に保つために、ホットフィックスブランチは開発ブランチにマージされます。
## トランクベースのアプローチ
次の図は、トランクベースのワークフローを示しています。トランクベースのワークフローでは、開発者は機能ブランチでローカルに機能をビルドおよびテストし、それらの変更をメインブランチにマージします。メインブランチはその後、開発環境、本番前環境、本番環境に合わせて順次構築されます。各環境間では、ユニットテストと統合テストが実行されます。
このワークフローを使用すると、すべての環境が同じコードベースで動作します。未リリースの機能を公開することなくメインブランチで変更を実装できるため、上位環境向けにホットフィックスブランチを作成する必要はありません。メインブランチは常に、安定しており、欠陥がなく、リリース可能な状態であると想定されます。これにより、メインブランチを CI/CD パイプラインのソースとして統合することができ、パイプライン内のすべての環境を通じてコードベースを自動的にテストおよびデプロイできます。