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

# トランクベースのアプローチによるリリース上の利点
<a name="releases"></a>

ホットフィックスが頻繁に必要になる理由の 1 つは、レガシーワークフローでは、開発者が作業しているアプリケーションの状態に、まだ本番環境で稼働していないいくつかの未リリースの機能が含まれている場合があることです。本番環境と開発環境は、スケジュールされたリリースが行われたときにのみ同期状態になり、その後、次のスケジュールされたリリースまで再びすぐに乖離し始めます。

スケジュールされたリリースを行うことは、完全な CI/CD プロセス内でも可能です。機能フラグを使用することで、本番環境へのコードのリリースを遅らせることができます。しかし、完全な CI/CD プロセスでは、スケジュールされたリリースが不要になるため、さらに柔軟性が向上します。結局のところ、CI/CD における重要なキーワードは*継続的*であり、これは変更が準備できた時点でリリースされることを示しています。下位のテスト環境と同期状態になることがほとんどないような、独立したリリース環境を維持することは避けてください。

パイプラインが完全な CI/CD になっていない場合、通常、上位環境と下位環境の乖離はブランチレベルで発生します。開発者は開発ブランチで作業し、スケジュールされたリリースのタイミングになったときにのみ更新される、個別のリリースブランチを維持します。リリースブランチと開発ブランチが乖離するにつれて、他の複雑さが発生する可能性があります。

環境が同期していないことに加えて、開発者が開発ブランチで作業し、本番環境よりもはるかに先行したアプリケーションの状態に慣れてしまうと、本番環境で問題が発生するたびに、開発者は本番環境の状態に再適応する必要があります。開発ブランチの状態は、本番環境よりも多くの機能がある分、先行していることがあります。開発者が毎日そのブランチで作業していると、本番環境に何がリリースされていて何がリリースされていないかを覚えておくことは困難です。これにより、他のバグを修正する際に新しいバグが導入されるリスクが高まります。この結果、永遠に続くかのような修正のサイクルが発生し、タイムラインが延び、機能のリリースが数週間、数か月、あるいは数年も遅れることになります。