トランクベースのアプローチによる環境整合性の利点

多くの開発者が知っているように、コードの 1 つの変更がバタフライ効果 (American Scientist の記事) を引き起こすことがあります。これは、一見無関係に見える小さな逸脱が連鎖反応を誘発し、予期しない結果を引き起こす現象です。その場合、開発者は根本原因を見つけるために徹底的な調査を行う必要があります。

科学者が実験を行う場合、被験体を実験群と対照群の 2 つのグループに分けます。この実験群と対照群は、実験でテストされる対象以外は完全に同一にすることが意図されます。実験群で発生したことが対照群では発生しない場合、その原因として考えられるのは、テストされている対象だけです。

デプロイにおける変更を実験群として、各環境を個別の対照群として考えてみてください。下位環境でのテスト結果が信頼できるのは、その対照が上位環境と同じである場合のみです。環境の逸脱が大きくなるほど、上位環境で欠陥が発見される可能性が高くなります。言い換えれば、コードの変更が本番環境で失敗する可能性がある場合、その変更が本番環境に到達しないように、先にベータ環境で失敗してくれたほうがはるかに望ましいということです。これが、最も下位のテスト環境から本番環境自体に至るまで、各環境が同期した状態を維持するためにあらゆる努力をする必要がある理由です。これを環境整合性と呼びます。

すべての完全な CI/CD プロセスは、できるだけ早く問題を発見することを目標としています。トランクベースのアプローチを使用して環境整合性を維持することで、実質的にホットフィックスの必要性を排除できます。トランクベースのワークフローでは、問題が最初に本番環境で出現することはまれです。

Gitflow アプローチでは、ホットフィックスは上位環境に直接デプロイされた後、開発ブランチに追加されます。これにより、将来のリリースに向けてその修正が保持されます。しかし、そのホットフィックスは、アプリケーションの現在の状態から直接開発およびテストされたものです。ホットフィックスが本番環境で完全に機能している場合でも、開発ブランチの新しい機能と相互作用する際に問題が発生する可能性があります。通常、ホットフィックスのためのホットフィックスをデプロイすることは望ましくないため、開発者はホットフィックスを開発環境に後付けで適合させようとして、余分な時間を費やすことになります。多くの場合、これは重大な技術的負債につながり、開発環境の全体的な安定性を低下させる可能性があります。

環境で障害が発生した場合は、すべての変更がロールバックされ、環境は以前の状態に戻されます。コードベースに何らかの変更を加えた場合は、最初のステージからパイプラインを再度開始する必要があります。本番環境で問題が発生した場合は、その修正も同様にパイプライン全体を通過する必要があります。下位環境を通過するのに追加でかかる時間は、通常、このアプローチを使用することで回避できる問題と比較するとごくわずかです。下位環境の全体的な目的は、本番環境に到達する前に問題を捕捉することにあるため、Gitflow アプローチによってこれらの環境をバイパスすることは、非効率かつ不要なリスクです。