問題タブ [code-freeze]

私は過去に継続的インテグレーション サーバーを使用して大きな成功を収めましたが、ソース コントロール システムでコード フリーズを実行する必要はありませんでした。

しかし、最近はどこを見ても、ほとんどのショップが、製品のリリースや新しいテスト バージョンの準備をするときに、コード フリーズという概念を使用しているようです。この考えは、私の現在のプロジェクトでも実行されます。

早期に頻繁にチェックインし、単体テスト、統合テスト、受け入れテストなどを使用する場合でも、コード フリーズが必要ですか?

すべての開発者に新しいコードをチェックインしないように依頼するよりも、SVN でコード フリーズを実装するためのより良い方法はありますか?
CruiseControl を実行しています。これにより、最新のビルドが環境に自動的にデプロイされます。そのため、新しいコードが入ってくると、以前に利用可能になったビルドが最新のものに変更されます。デプロイされたビルドが特定のブランチ/タグからのものであることを望み、新しいコードのチェックインがデプロイされたビルドに影響を与えないようにします。次回タグ付け/ブランチするときにのみ、新しいコードを再度デプロイする必要があります。どうすればこれを達成できますか?

バグのテストと修正以外で開発を停止する状況に対して、「コード フリーズ」という用語を使用することをコミュニティが許容できると考えるかどうか、私はただ興味があります。

開発状況

私たちは 3 番目で最後のスプリントを終えたところで、「コード フリーズ」と 2 週間の Q/A テストが続きます。これは大きなリリースであり、一部のコンポーネントの開発は 3 つのスプリントすべてを超えています。歴史的には「コード フリーズ」と呼んでいますが、バグを修正するためにコードをコミットしています。

問題

リリースのたびに、私は上司や同僚に修正を試みており、これを「機能の凍結」と呼ぶべきです。なぜなら、重いテストを開始するとすぐに、バグを見つけて修正するためにコードをコミットすることは明らかだからです。しかし、彼らはそれを「コードフリーズ」と呼んでいます。既知のバグがまだあり、「コード フリーズ」を宣言することがあります。

ウィキペディアの定義はここで私に同意するようです

分析

これらの状況を「コード フリーズ」と呼ぶのは、利害関係者に誤った信頼を与えるためのある種の意図的なダブル シンクだと思います。または、「コード フリーズ」の状況にあるふりをしているのです。なぜなら、スクラムに従って、すべてのスプリントの後に出荷可能なソフトウェアを用意する必要があり、スクラムに従っていることが期待されるからです。したがって、それが実際に何であるかではなく、スクラムが期待するものと呼ぶ必要があります。

結論

私はこれを分析しすぎていますか？状況の現実を無視するのは不健康だと思うので、それをそうではないものと呼ぶのをあきらめるか、根本的な問題を修正する必要があります. Code Freezes で同様の経験をした人はいますか?