私は非常に大規模な組織で働いたことがなく、「ビルド サーバー」を持つ会社で働いたこともありません。
彼らの目的は何ですか？
開発者がローカル マシンでプロジェクトをビルドしないのはなぜですか?
一部のプロジェクトは非常に大規模で、適切な時間内に構築するにはより強力なマシンが必要ですか?
ビルド サーバーが有用であると私が考える唯一の場所は、リポジトリにコミットされたものを常にビルドするビルド サーバーとの継続的な統合です。十分な規模のプロジェクトに取り組んでいないだけですか?
誰か、教えてください: ビルド サーバーの目的は何ですか?
与えられた理由は、実際には大きなメリットです。QA に進むビルドは、リポジトリからのみビルドするシステムからのみ取得する必要があります。このようにして、ビルド パッケージは再現可能で追跡可能です。開発者が独自のテスト以外のコードを手動で作成することは危険です。ものがチェックインされない、他の人の変更によって時代遅れになるなどのリスクが大きすぎます。
ビルド サーバーは、いくつかの理由で重要です。
彼らは環境を隔離します ローカルのCode Monkey 開発者は、あなたのマシンではコンパイルできないとき、「それは私のマシンでコンパイルできます」と言います。これは、非同期チェックインを意味するか、依存ライブラリが見つからないことを意味する可能性があります。Jar 地獄は .dll 地獄ほど悪くはありません。いずれにせよ、ビルド サーバーを使用することは、ビルドが不可解に失敗したり、誤って間違ったライブラリをパッケージ化したりすることを防ぐ安価な保険です。
ビルドに関連するタスクに焦点を当てています。これには、ビルド タグの更新、配布パッケージの作成、自動テストの実行、ビルド レポートの作成と配布が含まれます。自動化が鍵です。
彼らは (分散) 開発を調整します。標準的なケースは、複数の開発者が同じコード ベースで作業している場合です。バージョン管理システムは、この種の分散開発の心臓部ですが、ツールによっては、開発者がお互いのコードをあまりやり取りしない場合があります。開発者に悪いビルドのリスクを負わせたり、過度に積極的にコードをマージすることを心配させたりするのではなく、自動ビルドが適切なコードを認識し、ビルド アーティファクトを予測可能な方法で処理できるビルド プロセスを設計します。そうすれば、新しいファイルの依存関係をチェックインしないなど、開発者が何か問題をコミットしたときに、すぐに通知を受けることができます。ステージングされた領域でこれを行うと、ビルドされたコードにフラグを付けて、開発者がローカル ビルドを壊すコードをプルしないようにできます。PVCS は、プロモーション グループのアイデアを使用して、これを非常にうまく行いました。Clearcase もラベルを使用してそれを行うことができますが、多くのショップが提供するよりも多くのプロセス管理が必要になります。
彼らの目的は何ですか？
開発者のマシンに負荷をかけ、安定した再現可能なビルド環境を提供します。
開発者がローカル マシンでプロジェクトをビルドしないのはなぜですか?
複雑なソフトウェアでは、「コンパイルする」だけで驚くほど多くのことがうまくいかない可能性があるからです。私が実際に遭遇した問題：
すべてのパブリック リリースは、ソース管理から空のフォルダーへの取得から始まるため、驚くほど安定性が向上しています。以前は、「Joe が新しい DLL をくれたときに解決した」「おかしな問題」がたくさんありました。
一部のプロジェクトは非常に大規模で、適切な時間内に構築するにはより強力なマシンが必要ですか?
「合理的」とは？ローカル マシンでバッチ ビルドを実行すると、できないことがたくさんあります。開発者にお金を払ってビルドを完了するのではなく、IT にお金を払って実際のビルド マシンを購入してください。
十分な規模のプロジェクトに取り組んでいないだけですか?
サイズは確かに 1 つの要因ですが、唯一の要因ではありません。
ビルド サーバーは、継続的インテグレーション サーバーとは異なる概念です。CI サーバーは、変更が加えられたときにプロジェクトをビルドするために存在します。対照的に、ビルド サーバーは、クリーンな環境でプロジェクト (通常はタグ付きリビジョンに対するリリース) をビルドするために存在します。開発者によるハッキング、微調整、承認されていない構成/アーティファクト バージョン、またはコミットされていないコードがリリースされたコードに含まれないようにします。
ビルド サーバーは、チェックイン時にすべてのユーザーのコードをビルドするために使用されます。コードはローカルでコンパイルできますが、他のユーザーが行ったすべての変更が常に反映されるわけではありません。
すでに述べたことを追加するには：
Microsoft Office チームで働いていた元同僚は、完全なビルドに 9 時間かかることもあると教えてくれました。あなたのマシンでそれをするのは最悪ですよね？
ビルドとテストが確実に機能し、アーティファクトに依存しないようにするために、以前のバージョンのアーティファクト (および構成の変更) のない「クリーンな」環境を用意する必要があります。分離する効果的な方法は、別のビルド サーバーを作成することです。
安定性、トレーサビリティ、再現性に関しては、これまでの回答に同意します。（たくさんの「ity」ですよね？）。多くのビルドサーバーを備えた大企業 (ヘルスケア、金融) でしか働いたことがないので、それはセキュリティに関するものでもあると付け加えておきます。映画「オフィス スペース」を見たことがありますか? 不満を持った開発者が自分のローカル マシンでバンキング アプリケーションを構築し、他の誰もそれを見たりテストしたりしなければ... ブーム。スーパーマンⅢ。
これらのマシンは、いくつかの理由で使用されますが、すべて優れた製品を提供するために役立ちます。
1 つの用途は、一般的なエンド ユーザー構成をシミュレートすることです。製品は、すべての開発ツールとライブラリがセットアップされたコンピューターで動作する可能性がありますが、エンド ユーザーはおそらくあなたと同じ構成を持っているわけではありません。さらに言えば、他の開発者もあなたとまったく同じ設定をしているわけではありません。コードのどこかにハードコーディングされたパスがある場合、おそらくマシン上で機能しますが、Dev El O'per が同じコードをビルドしようとすると機能しません。
また、誰が最後に製品を壊したか、どの更新プログラムで、製品がどこでリグレッションしたかを監視するためにも使用できます。新しいコードがチェックインされるたびに、ビルド サーバーがそれをビルドし、それが失敗した場合、何かが間違っていて、最後にコミットしたユーザーに問題があることは明らかです。
一貫した品質とビルドを「マシンから」取得して環境エラーを見つけ、ソース管理にチェックインするのを忘れたファイルもビルドエラーとして表示されるようにします。
また、コード署名などでデスクトップ上で行うには多くの時間がかかるため、インストーラーの作成にも使用します。
たぶん私だけ...
誰もがそうすべきだということに同意すると思います
しかし、自動的にビルドされたバージョンについては誰も気にしません。自動ビルドで何かが壊れていたが、もう壊れていない場合 - 誰が気にしますか? 進行中の作業です。誰かがそれを修正しました。
リリース バージョンを実行する場合は、リポジトリからビルドを実行します。そして、サーバーが動作する6時間ごとではなく、その時点でリポジトリのバージョンにタグを付けたいと確信しています。
したがって、「ビルド サーバー」は単なる誤称であり、実際には「継続的なテスト サーバー」である可能性があります。そうでなければ、それはほとんど役に立たないように聞こえます。
ビルド サーバーで使用できるものと同じライブラリとそれらのライブラリのバージョンが、運用/テスト ボックスにインストールされていることがわかるように、1 つを使用します。
それは私たちの管理とテストに関するものです。ビルド サーバーを使用すると、バージョン管理からメインの「トランク」ラインをビルドできることが常にわかっています。ワンクリックでマスター インストールを作成し、それを Web に公開できます。コードがチェックインされるたびにすべての単体テストを実行して、コードが機能することを確認できます。これらすべてのタスクを 1 台のマシンにまとめることで、繰り返し正しく行うことが容易になります。
開発者が自分のマシンでビルドできるというのはあなたの言うとおりです。
しかし、これらは私たちのビルド サーバーが私たちにもたらすものの一部であり、私たちは洗練されたビルド メーカーではありません。
ビルド サーバーは、場合によっては 2 時間以上かかることもある、リポジトリに配置された通常は大規模なプロジェクトのコンパイル タスク (夜間ビルドなど) をスケジュールするために使用されます。
ビルド サーバーは、他の人が所有権を取得する権利を持っている可能性がある場合に、ビルドを再現するために必要なすべての部分をキャプチャできる、エスクローの基盤も提供します。
ビルド サーバーは、コードの一種のセカンド オピニオンを取得します。チェックインすると、コードがチェックされます。機能する場合、コードの品質は最低です。
さらに、低水準言語は高水準言語よりもコンパイルに時間がかかることに注意してください。「ほら、私の .Net プロジェクトは数秒でコンパイルされます! 何が大変なの?」と考えるのは簡単です。しばらく前に C コードをいじる必要があり、コンパイルにどれだけ時間がかかるか忘れていました。