4

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

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

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

4

5 に答える 5

6

継続的インテグレーションは「ビルド」ですが、開発サイクルのプログラミング部分の一部です。TDD の「テスト」が開発サイクルのプログラミング部分の一部であるように。

全体的な開発サイクルの一部として、引き続きビルドとテストが行​​われます。

継続的な統合とテストのポイントは、フィードバック ループを短縮し、プログラマーの可視性を高めることです。最終的に、これはテストとビルドの問題が少なくなることを意味しますが、開発サイクルの元の部分を行わなくなるという意味ではありません。開発サイクルの早い段階で発見されました。

したがって、出荷するもののベースラインが期待どおりであることを確認するために、コード フリーズ (または少なくともブランチ) を行う必要があります。誰かが高い信頼度で何かを実装できるからといって、それが同じ最終サイクルを通過せずにリリースされるわけではありません。コード フリーズはその重要な部分です。

CI を使用すると、最終的なビルド、テスト、およびリリースの信頼性が非常に高くなる可能性があるため、コードのフリーズは非常に短くなる可能性があります。ブランチが必要ないため、小さなプロジェクトではコードのフリーズさえ存在しない可能性があります。リリースしてすぐに戻ることができます。次の一連の機能の開発に非常に迅速に移行できます。

また、CI と TDD により、これまで行われてきた継続的な QA とは対照的に、最終的なビルドとテストのフェーズを従来のウォーターフォール (すべての開発を行い、すべてのテストを行い、その後リリースする) に近づけることができることも付け加えたいと思います。毎週または毎月のビルドのプロジェクト。テスターは CI ビルドを使用して初期のフィードバックを提供できますが、これは実質的に、機能ではなく安定性と信頼性を求める最終テストとは異なる種類のフィードバックです (ユニットの「テスト」では明らかに見落とされていました)。開発者が構築した)。

于 2008-11-11T21:04:48.873 に答える
3

継続的な統合は実行時の回帰テストに取って代わるものではないため、コードのフリーズは重要です。

アプリケーションをビルドして単体テストに合格することは、課題のほんの一部にすぎません。理想的には、リリースのためにコードをフリーズするときは、次の 2 つのことを承認していることになります。

  • このコードは完全にリグレッションされており、欠陥はありません
  • このコードは、(SOX 準拠のために) 実稼働する必要があるコードとまったく同じです。

最新の SCM を使用している場合は、その時点でコードをフォークし、ブランチで次のリリースの作業を開始し、プロジェクトがデプロイされたときにマージを実行します。(もちろん、重大なパッチを適用する必要がある場合は、その時点をロールバックできるようにラベルを配置してください)。

コードが「リリースモード」になったら、触れないでください。

私たちの典型的なプロセス:

Development
   ||
   \/
   QAT 
   ||
   \/
   UAT => Freeze until deploy date => Deploy  => Merge and repeat
            \                                     /
             \- New Branch for future dev -------/

もちろん、通常、開発中に多くの並列ブランチがあり、UAT の前にリリース ストリームにマージされます。

于 2008-11-11T20:59:17.090 に答える
1

コードのフリーズは、開発よりも QA に関係しています。コード フリーズは、QA が次のように述べたポイントです。「十分です。これまでに追加された新機能を完全にテストする帯域幅しかありません。」これは、開発者がより多くの機能を追加する帯域幅を持っていないという意味ではありません.QAには、すべてが連携して動作することを確認するために、静止コードベースで時間が必要なだけです.

全員が継続的インテグレーション モード (QA を含む) を使用している場合、これは非常に短い時間の凍結に過ぎない可能性があり、QA は、パッケージが出荷される直前にパッケージ全体に最終的な承認の印を付けます。

それはすべて、QA と回帰テストが開発サイクルにどれだけ緊密に統合されているかにかかっています。

私は、SCM の分岐と、開発者が QA がテストしているものとは別のコード分岐で続行できるようにすることについて、既に述べた投票を支持します。それはすべて同じものに戻ります。QA および回帰テストでは、リリース前の一定期間、静止コード ベースが必要です。

于 2008-11-11T21:10:38.487 に答える
0

私は文脈主導型の人のように聞こえるかもしれませんが、答えは「場合による」です。

Code Freeze は、問題に対処するための戦略です。問題がない場合は、問題に対処するのが得意ですが、いいえ、必要ありません。問題に対処するための別の手法がある場合は、いいえ、必要ありません。

コード フリーズは、リスクを軽減するための 1 つの手法です。もたらす利点は、安定性とシンプルさです。それがもたらすデメリットは、

もう 1 つの手法は、「フィーチャー ブランチ」などの分岐を使用することです。分岐の欠点は、分岐を処理するコスト、変更をマージするコストです。

リスクを軽減するために説明している手法は、迅速なフィードバックを提供するための自動テストです。ここでのトレードオフは、速度の増加とリスクの増加です (いくつかのバグを見逃すことになります)。

これらのアプローチの中で、私は自動テストを好みます。しかし、失敗のコストが非常に高い場合など、Code Freeze が多くの価値を提供する状況もあります。

于 2008-11-11T21:47:41.253 に答える
0

それぞれの新しい機能がバグの新しいソースになる可能性があるため、コードのフリーズは重要だと思います。確かに回帰テストは優れており、この問題の解決に役立ちます。しかし、コード フリーズにより、開発者は現在未解決のバグの修正に集中し、現在の機能セットをリリースに値する状態にすることができます。

せいぜい、コードのフリーズ中に新しいコードを本当に開発したい場合は、フリーズしたツリーをフォークし、そこで作業を行い、フリーズ後にフォークしたツリーをマージして戻します。

于 2008-11-11T20:58:01.413 に答える