build - 開発者はサンドボックスで作業する必要がありますか?

Question

開発者がソース管理にチェックインする前に開発環境で単体テストを実行する場合、その環境 (テストの失敗を含む) を共有する必要がありますか?

すべてのビルドを公開する必要がありますか?

Answer 1

開発者のビルドを公開するのは非現実的だと思います。ビルドの失敗 (単体テストの失敗) が発生するたびにチーム メンバーを悩ませたくありません。

あなたは常に何らかの問題の解決策を作成している最中であり、最初はうまくいかない可能性があるため、単体テストの失敗が頻繁に発生します。特に、コードの開発にテスト駆動型のアプローチを採用している場合: 最初に単体テストを作成し、機能を実装して、それ以上失敗しないようにします。

Answer 2

子供たちはサンドボックスで遊ぶべきです;)、ソフトウェア開発者は自分の PC でプレイし、コードが一定の品質レベルを満たしていると感じたらいつでもコードをコミットするべきです。誰もが小さなテスト済みのコードを定期的にコミットして更新すると、私の経験では、深刻な問題は発生せず、建設的なフィードバックのみが発生し、誰かが何かを叫ぶことがあります。最終的にソフトウェアを一般/顧客にリリースすることは別の話です。これには、広範なテスト、リリース ノートの作成、マニュアルの更新、マーケティングなどが必要です。

Answer 3

サンドボックスで作業するのは良い考えだと思います。何度か救われました。私は通常、開発に使用するいくつかの異なる仮想マシンをあちこちに浮かべており、それをひどく台無しにしても、マシンが再構築されるのを待つ必要はありません。

単純な開発者ビルドのすべてのテスト結果を公開する必要はないと思います。すべての失敗を公開することで誰かの気持ちを傷つけることについてはあまり心配していませんが、彼らが提供する情報が役に立たないのではないかと心配しています。

開発者がチェックイン時に合格したテスト結果を提出する必要があるようなシステムを調査するのは興味深いことですが、それでさえ物事を推し進めていると思います。生産性に悪影響を与える可能性があります。開発者は、コーディング以外でやるべきことをすでに十分に抱えています。

Answer 4

これにはどのような利点がありますか? 特に、すべての開発者によるすべての picayune テストの失敗について、誰もが電子メールを受け取ることを意味します。

これは単に全員の気を散らすのに役立ちます。

できるという理由だけで何かをしたいという誘惑を避けてください。要件に合わせてプロセスを推進します。できるという理由だけで新しいプロセスを作成しないでください。

Answer 5

はい、開発者は可能であればサンドボックスで作業する必要があります。デフォルトでは、すべてのビルドを公開する必要はありません。TDD は、テストとコードの両方に複数の失敗と改善をもたらします。ビルドを公に共有するのは面倒かもしれませんが、他の開発者が行って見に行くのに十分気をつけていれば、他の開発者が何をしているのかを見ることができるはずです。要請があった場合は、公開する必要があります。彼らが何かをテストしたという証拠を求めている場合は、コードをチェックインした後に単体テストを実行することで十分な証拠になるはずです。

変更を自由にテストできる環境、ツール、および自由を開発者に提供すると、ソフトウェアの安定性と品質が向上します。理論のテストとトラブルシューティングには、小さなインクリメンタル ビルドが必要になることがよくあります。サンドボックスが高価な場合は、それを使用するための時間を確保する必要があります。各開発者にプライベート サンドボックスを提供すると、コードの分岐が長時間に及ぶ可能性があります。この質問をする動機は何ですか？開発者が何かを隠そうとしている場合は、その問題の根本原因を突き止めます。コストを抑えたい場合は、予約モデルを検討してください。