翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CI/CD プロセスの違い

CI/CD パイプラインは、最新のトランクベースのワークフローを使用します。このワークフローでは、開発者は、CI/CD パイプラインの CD 部分を通じて構築およびテストされるメインブランチ (またはトランク) に、小規模で頻繁な更新をマージします。このワークフローは、開発ブランチとリリースブランチをリリーススケジュールで区切る Gitflow ワークフローを置き換えました。多くの組織では、Gitflow は依然としてバージョン管理とデプロイの一般的な方法です。ただし、現在はレガシーと見なされており、CI/CD パイプラインに統合するのは難しい場合があります。

多くの組織では、Gitflow ワークフローからトランクベースのワークフローへの移行は不完全であり、その結果、途中でどこかで停止し、CI/CD に完全に移行することはありません。ある意味、パイプラインはレガシーワークフローの特定の残骸に縛られ、過去と現在の間の移行状態のままになります。Git ワークフローの違いを確認し、レガシーワークフローの使用が以下にどのように影響するかを学習します。

最新の設定でレガシー Git ワークフローの残余を簡単に識別できるように、Gitflow を最新のトランクベースのアプローチと比較してみましょう。

Gitflow アプローチ

次の図は、Gitflow ワークフローを示しています。Gitflow アプローチでは、複数のブランチを使用して、複数の異なるバージョンのコードを同時に追跡します。開発者が現在のバージョンのコードで作業している間、将来のいずれかの時点でアプリケーションの更新のリリースをスケジュールします。トランクベースのリポジトリでは、機能フラグを使用してこれを実行できますが、デフォルトでは Gitflow に組み込まれています。

Gitflow アプローチの結果の 1 つは、アプリケーション環境が通常同期していないことです。標準の Gitflow 実装では、開発環境はコードの現在の状態を反映し、本番稼働前環境と本番稼働環境は最新のリリースからのコードベースの状態でフリーズしたままです。

これにより、デベロッパーが作業するコードベースが、リリースされていない機能を公開せずに本番環境にマージできないため、本番環境に不具合が発生した場合にモノが複雑になります。Gitflow がこの状況を処理する方法は、修正プログラムを使用することです。修正ブランチはリリースブランチから作成され、上位環境に直接デプロイされます。ホットフィックスブランチは、コードを最新の状態に保つために開発ブランチにマージされます。

トランクベースのアプローチ

次の図は、トランクベースのワークフローを示しています。トランクベースのワークフローでは、開発者は特徴量ブランチでローカルに特徴量を構築してテストし、それらの変更をメインブランチにマージします。メインブランチはその後、開発環境、本番前環境、本番環境に合わせて順次構築されます。ユニットテストと統合テストは、各環境間で行われます。

このワークフローを使用すると、すべての環境が同じコードベースで動作します。リリースされていない機能を公開せずにメインブランチに変更を実装できるため、上位環境のホットフィックスブランチは必要ありません。メインブランチは常に安定しており、欠陥がなく、リリースする準備ができていることを前提としています。これにより、CI/CD パイプラインのソースとして統合できます。これにより、パイプライン内のすべての環境を通じてコードベースを自動的にテストしてデプロイできます。