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

多くの開発者が知っているように、コードの 1 つの変更によってバタフライ効果が生じることがあります (アメリカの科学者の記事）。ここでは、無関係に見える小さな偏差が、予期しない結果を引き起こす連鎖反応を引き起こします。その後、開発者は根本原因を発見するために完全に調査する必要があります。

科学者が実験を実行すると、テスト対象を実験グループとコントロールグループの 2 つのグループに分けます。目的は、実験でテストされるモノを除いて、実験グループとコントロールグループを完全に同一にすることです。実験グループで、コントロールグループで発生しない何かが発生した場合、唯一の原因はテスト対象のモノです。

デプロイの変更を実験グループと見なし、各環境を個別のコントロールグループと見なします。より低い環境でのテスト結果は、コントロールが上位環境と同じ場合にのみ信頼性があります。環境が逸脱するほど、上位環境の欠陥を検出する可能性が高くなります。つまり、コードの変更が本番環境で失敗する場合は、最初にベータ版に失敗して、本番環境に移行しないようにすることをお勧めします。そのため、テスト環境が最も低い環境から本番稼働環境まで、各環境を同期させるようにあらゆる努力をする必要があります。これは環境の整合性と呼ばれます。

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

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

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