デイリービルドはどれほど重要ですか？[閉まっている]

ジョエルテストの基準の1つは、毎日のビルドです。アイデアは、ビルドが壊れた場合、それを壊した人がそれを修正するために周りにいるということです。ビルドを修正できない場合は、全員が古いバージョンをチェックアウトして作業する必要があります。一元化されたバージョン管理では、マージと分岐を可能な限り避けることが重要であるため、これがいかに悪いかを理解できますが、これは分散バージョン管理にとってささいな迷惑のように聞こえます。これに同意しますか？毎日のビルドが重要な理由は他にもありますか？

ここで注意すべき重要なことは、通常のビルドがエラーをキャッチするのに役立つということです。毎日である必要はありませんが、しばしば十分です。理想的には、単体テストも実行できます。

目標は、最終テスト段階の前にいつビルドが壊れるかを見つけ、できるだけ早くそれらを見つけることです。

メインの開発ブランチを構築するためにセットアップするだけです。

私たちは職場でそれを使用しますが（1時間ごとにビルドします）、セットアップを忘れると、リリースする数時間前に問題が見つかることがよくあります。

これに少し追加する必要があります（そして@GoodEnoughs）：

しかし、これは分散バージョン管理にとってささいな迷惑のように聞こえます。

はっきり言っていいえ-「サーバー」ビルドが行うことは、トランクがビルドされて、テストをクリーンから多少なりともパスするということです（環境に対して行う必要がある設定の量は少なくなります）。

私はDVCSへの切り替えを考えていますが、それを行ったとしても、あなたは私の絶え間ない統合から私の継続的な統合を引きずってしまいます。

簡単な例を挙げると、機能「a」を開発しており、機能「b」を開発しているか、ある時点ですべてをつなぎ合わせる必要があります。あなたのマシン上で、それは他のどこにもありません。したがって、ビルドを「トランク」にプッシュすると、継続的インテグレーションがトリガーされ、ビルドが失敗します。誰かがあなたの非常に完全ではないコードをプルする前に、ステップを踏むことができます。

複数の開発者がいるプロジェクトで作業している場合、リリースバージョンの出所（トランクが有効）を定義できるようにする必要があります。これは、バージョン管理の仕組みに関係なく当てはまります。

機能（特に他の人が依存関係にある機能）を追加した場合、「ライブ」にプッシュされたときに、開発環境以外の場所でテストがビルドおよびパスされることを確信できます。それ以上に、私は自分のビルドサーバーからのビルドからデプロイします。これは、「決定的な」ビルドを指定する方法です。最終的には、ユーザーがトリガーする展開ビルドを作成します。その周りで働くことができると言ってはいけません-あなたがそれを必要とするなら、あなたはできません（そして、私は不足しているファイルを見つけてコミットするためにオフィスのラウンド開発ボックスをスクランブルしました）。

それはすべて少し強いですか？わからない-しかし、私のビルドサーバーは、私が手に入れたくないものの1つです。

私が信じるデイリービルドは非常に重要です。異なるタイムゾーンに分散したチームがある場合、ほとんどのチームにとってほぼ「一日の終わり」である時間を見つけることが最善です。さらに、デイリービルドに自動化されたテストコンポーネントがある場合は、それがより望ましいです。

中央のソース管理システムの時代には、ソースコードに何かが変更された場合、5〜10分ごとに実行される継続的なビルドを推奨していました。コンパイルエラーは、ほとんどのチームを遅くする可能性があるためです。分散ソース管理システムを実行している組織では、開発者が「元の」コードベースに直接触れる頻度が少ないため、継続的なビルドはそれほど必要ないかもしれません。

理想的には、構築するのに半日以上かかるような大規模なものを構築しない限り、1日に複数回構築することになります。HudsonやTeamCityなどの継続的インテグレーションサーバーをセットアップしたらと、通常1時間ごとまたはコミットごとにビルドが自動的に行われ、問題がある場合は通知されます。

特にビルドの一部として自動化されたテストも実行している場合は特に、エラーを早期にキャッチするのに適した方法です。これは、ビルドが1つの開発者のマシンで機能するが、リポジトリまたは環境から何かが省略されたため他の場所では機能しない構成エラーを見つけるのに特に役立ちます。

また、より高度な継続的統合サーバーを使用すると、メトリックスを経時的に追跡できます（コードカバレッジの割合、ビルド時間、コードの行など）。

デイリービルドは大丈夫です。正直に言うと、ジョエルのテストは最近では少し時代遅れだと思います。

私の意見では、あなたはユニット、システム、機能レベルのテストケースを実行し、理想的にはパッケージ化して同時に環境のようなステージに展開し、DBと環境のバージョン管理メカニズムを検証しながら、一日中継続的に構築する必要があります期待どおりに動作しています。

ビルドまたは展開時間が非常に長い場合、これらの問題の一部を物理またはソフトウェアRAMディスク、高速インターネット接続、ビルドの並列化などで最適化することを検討してください。 。

毎日のビルドは重要ではありません。常に成功する毎日のビルド（または1時間だけ壊れるビルド）。ビルドの70％が破損しているときにCIを使用することはあまり役に立ちません。これは、ほとんどのものが破損している場合、エラーの特定に役立たないためです。

毎日のビルド、テスト、ステージングサーバーへの展開が必要だと思います。

「デイリービルド」の背後にある考え方は、テスターとプロジェクトマネージャーが実行できるものを常に用意し、誰もがプロジェクトの実際の状態を把握できるようにすることです。

以前は、「毎日のビルド」後のデスクトップアプリでは、テスターまたはプロジェクトマネージャーがすぐにアプリを実行できるため、展開手順について言及する必要はありませんでした。