3つのブランチ{Dev、Test、Release}があり、ブランチごとに継続的インテグレーションが設定されます。各ブランチにビルド品質を割り当てられるようにしたい、つまりDev-テストの準備ができています...
アドバイス/ベストプラクティスのアプローチを提供できる、これに関する経験はありますか？
私たちはTFS2008を使用しており、ビルド品質が組み込まれていることを認識しています。それは、品質を適用するタイミングであり、人々が使用する品質の種類が私たちが求めているものです。
ありがとう
:)
ここでの目標は、各ブランチで可能な限り最高の品質を実現し、そのレベルの品質を検証する負担とバランスを取ることです。
どのブランチでも品質を落とすことは常に有害です。Devブランチを地獄に行かせて、マージする前に修正できるとは思わないでください。次の2つの理由により、うまく機能しません。
回復は予想よりも難しいです。ブランチがひどく壊れているとき、それが実際にどれほど壊れているかはわかりません。それは、各問題が他の問題を隠しているためです。また、途中で他の問題に遭遇するため、問題を進展させることも困難です。
品質を落とすと何も節約できません。人々は時々「品質、コスト、スケジュール-2つ選んでください」などと言います。ここでの誤った仮定は、品質を落とすことによって「節約」するというものです。問題は、品質が低下するとすぐに「速度」、つまり作業を完了する速度も低下することです。良いニュースは、高品質を維持することは実際には余分なコストがかからないことであり、誰もが高品質のコードベースでの作業を楽しんでいます。
あなたがしなければならない妥協は、あなたが品質 を検証するのにどれだけの時間を費やすかということです。
テスト駆動開発を上手くやれば、非常に高速で信頼性の高い単体テストの包括的なセットができあがります。これらの品質のために、チェックインする前に開発者に実行してもらい、各ブランチで定期的に実行してもらい、常に100％合格するように要求することができます。また、進行中にリファクタリングを続けることもできます。これにより、プロジェクトの存続期間中、速度を高く保つことができます。
同様に、自動統合/顧客テストを適切に記述して、それらが迅速かつ確実に実行される場合は、それらも頻繁に実行し、常に合格するように要求できます。
一方、自動テストが不安定な場合、実行速度が遅い場合、または「既知の障害」で定期的に操作する場合は、ユーザーがテストを実行する必要がある頻度を減らす必要があり、多くの費用がかかります。これらの問題に取り組む時間の。最悪だ。そこに行かないでください。
最悪の場合、ほとんどのテストは自動化されていません。人々はこれらのことに本当に遅いので、あなたはそれらを頻繁に実行することはできません。非リリースブランチの品質は低下し、マージ速度と開発速度も低下します。
決定論的かつ再現可能な方法でビルドの品質を評価することは、間違いなく困難です。次のことをお勧めします。
これら 2 つの項目が特定の Dev ビルドで満たされている場合、このビルドをテストに昇格させても QA チームの時間が無駄にならないと合理的に確信できます。