「サーバーの構築」のポイントは何ですか？
私は非常に大規模な組織で働いたことはありませんし、「サーバーを構築」する会社で働いたこともありません。
彼らの目的は何ですか？開発者がローカルマシンでプロジェクトを構築しないのはなぜですか？いくつかのプロジェクトが非常に大きいため、妥当な時間内にビルドするにはより強力なマシンが必要ですか？
ビルドサーバーが便利だと思う唯一の場所は、リポジトリにコミットされているものを常にビルドしているビルドサーバーとの継続的な統合です。十分な規模のプロジェクトに取り組んでいないだけですか？
誰か、私に教えてください：ビルドサーバーの目的は何ですか？
与えられた理由は、実際には大きな利点です。 QAに移動するビルドは、リポジトリからのみビルドするシステムからのみ取得する必要があります。このようにして、ビルドパッケージは再現可能で追跡可能です。開発者が自分のテスト以外のコードを手動で作成するのは危険です。チェックインされなかったり、他の人の変更などで古くなったりするなどのリスクが大きすぎます。
ビルドサーバーはいくつかの理由で重要です。
彼らは環境を隔離しますローカル Code Monkey開発者 は、あなたの環境でコンパイルできないとき、「myマシンでコンパイルします」と言います。 。これは、非同期チェックインを意味するか、依存ライブラリが見つからないことを意味する場合があります。 Jar hellは.dll hellほど悪くはありません。いずれにせよ、ビルドサーバーを使用することは、ビルドがミステリアスに失敗したり、誤って間違ったライブラリをパッケージ化したりすることのない安価な保険です。
ビルドに関連するタスクに焦点を合わせます。これには、ビルドタグの更新、配布パッケージの作成、自動テストの実行、ビルドレポートの作成と配布が含まれます。オートメーションが重要です。
彼らは（分散）開発を調整します。標準的なケースは、複数の開発者が同じコードベースで作業している場合です。バージョン管理システムは、この種の分散開発の中心ですが、ツールによっては、開発者がお互いのコードとあまりやり取りしない場合があります。開発者に悪いビルドのリスクを負わせたり、コードを過度に積極的にマージすることを心配する代わりに、自動ビルドが適切なコードを確認し、ビルドアーティファクトを予測可能な方法で処理できるビルドプロセスを設計します。そのようにして、開発者が新しいファイルの依存関係をチェックインしないなど、問題のある何かをコミットした場合、迅速に通知できます。ステージング領域でこれを行うと、開発者がローカルビルドを壊すコードをプルしないように、ビルドされたコードにフラグを立てることができます。 PVCSは、プロモーショングループのアイデアを使用してこれを非常にうまく行いました。 Clearcaseもラベルを使用してこれを実行できますが、多くのショップが提供するよりも多くのプロセス管理が必要になります。
その目的は何ですか？
デベロッパーマシンをロードし、安定した再現可能なビルド環境を提供します。
開発者がローカルマシンでプロジェクトを構築しないのはなぜですか？
複雑なソフトウェアを使用しているため、驚くほど多くのことが「コンパイル」するだけでうまくいかないことがあります。私が実際に遭遇した問題：
- さまざまな種類の依存関係チェックが不完全であり、バイナリが更新されない。
- サイレントに失敗する発行コマンド、ログのエラーメッセージは無視されます。
- ソース管理にまだコミットされていないローカルソースを含めてビルドします（残念ながら、「いまいましい顧客」メッセージボックスはまだありません。）.
- 別のフォルダからビルドすることで上記の問題を回避しようとすると、一部のファイルが間違ったフォルダから選択されました。
- バイナリが集約されるターゲットフォルダには、リリースに含まれない古い開発者ファイルが含まれています
すべてのパブリックリリースは、ソース管理から空のフォルダーへの取得で始まるため、驚くほど安定性が向上しています。以前は、「Joeが新しいDLLをくれたときに立ち去った」「おかしな問題」がたくさんありました。
一部のプロジェクトは非常に大きいため、妥当な時間内にビルドするにはより強力なマシンが必要ですか？
「合理的」とは何ですか？ローカルマシンでバッチビルドを実行すると、できないことがたくさんあります。ビルドを完了するために開発者に支払うのではなく、ITに支払いをして、実際のビルドマシンをすでに購入します。
十分な規模のプロジェクトに取り組んでいないだけですか？
サイズは確かに1つの要素ですが、それだけではありません。
ビルドサーバーは、継続的インテグレーションサーバーとは異なる概念です。 CIサーバーは、変更が行われたときにプロジェクトをビルドするために存在します。対照的に、クリーンな環境でプロジェクト（通常はタグ付きリビジョンに対するリリース）をビルドするビルドサーバーが存在します。開発者がハッキング、調整、未承認の構成/アーティファクトバージョン、またはコミットされていないコードがリリースされたコードに組み込まれないようにします。
ビルドサーバーは、チェックイン時に全員のコードをビルドするために使用されます。コードはローカルでコンパイルできますが、ほとんどの場合、他の人がすべての変更を常に行うことはできません。
安定性、追跡可能性、再現性に関するこれまでの回答に同意します。 （多くの '性'？）多くのビルドサーバーを使用する大企業（ヘルスケア、財務）でしか働いたことがないので、セキュリティも重要だと付け加えます。映画「Office Space」を見たことがありますか？不満を抱く開発者が自分のローカルマシンで銀行業務アプリケーションを構築し、他の誰もそれを見たりテストしたりしない場合... BOOM。スーパーマンIII。
すでに言われたことを追加するには：
元同僚がMicrosoft Officeチームで働いており、完全なビルドには9時間かかることがあると教えてくれました。 [〜＃〜] your [〜＃〜] machineで実行するのは面倒ですよね。
ビルドとテストが機能し、アーティファクトに依存しないことを保証するために、以前のバージョンのアーティファクト（および構成の変更）のない「クリーンな」環境が必要です。効果的な分離方法は、個別のビルドサーバーを作成することです。
これらのマシンはいくつかの理由で使用されており、すべてが優れた製品を提供するのに役立ちます。
1つの用途は、一般的なエンドユーザー構成をシミュレートすることです。製品は、すべての開発ツールとライブラリがセットアップされたコンピューターで動作する可能性がありますが、エンドユーザーはおそらくあなたと同じ構成を持たないでしょう。さらに言えば、他の開発者もあなたとまったく同じセットアップを持っていません。コードのどこかにハードコードされたパスがある場合、おそらくマシン上で動作しますが、Dev El O'perが同じコードをビルドしようとすると動作しません。
また、誰が製品を最後に壊したか、どの更新で、どこで製品が後退したかを監視するために使用できます。新しいコードがチェックインされるたびに、ビルドサーバーがそれをビルドし、それが失敗した場合、何かが間違っていることと、最後にコミットしたユーザーに障害があることは明らかです。
一貫した品質を確保し、環境エラーを特定するために「マシンから」ビルドを取得し、ソース管理へのチェックインを忘れたファイルもビルドエラーとして表示されるようにします。
また、コード署名などを使用してデスクトップ上で行うには多くの時間がかかるため、インストーラーの作成にも使用します。
実稼働/テストボックスに、ビルドサーバーで使用可能なものと同じライブラリとそれらのライブラリのバージョンがインストールされていることを確認するために使用します。
管理とテストについてです。ビルドサーバーを使用すると、バージョン管理からメインの「トランク」ラインをビルドできることが常にわかります。ワンクリックでマスターインストールを作成し、Webに公開できます。コードがチェックインされるたびにすべての単体テストを実行して、コードが機能することを確認できます。これらすべてのタスクを1台のマシンにまとめることで、繰り返し正しい作業を簡単に行えるようになります。
開発者が自分のマシンで構築できるのはあなたです。
しかし、これらはビルドサーバーが購入するものの一部であり、高度なビルドメーカーではありません。
- バージョン管理の問題（以前の回答で言及されているものもあります）
- 効率。開発者は、ローカルでビルドを行うために停止する必要はありません。サーバーでキックオフして、次のタスクに進むことができます。ビルドが大きい場合、それは開発者のマシンが占有されていない時間です。継続的インテグレーションと自動化されたテストを行う人にとっては、さらに良いでしょう。
- 集中化。ビルドマシンには、ビルドを作成し、それをUAT環境に配布し、さらに実稼働ステージングに配布するスクリプトがあります。それらを1か所に保持することで、同期を維持する手間が軽減されます。
- セキュリティ。ここではあまり特別なことはしていませんが、システム管理者は、特定の承認済みエンティティのみがビルドサーバー上で本番移行ツールにアクセスできるようにすることができると確信しています。
たぶん私はただ一人です...
誰もがそうすべきだと思うと思う
- ファイルリポジトリを使用する
- リポジトリから（およびクリーンな環境で）ビルドします
- 連続したテストサーバー（クルーズコントロールなど）を使用して、「修正」後に何かが壊れていないか確認します
しかし、誰も自動的にビルドされたバージョンを気にしません。自動ビルドで何かが壊れたが、それはもはやないとき-誰が気にしますか？それは進行中の作業です。誰かがそれを修正しました。
リリースバージョンを実行する場合は、リポジトリからビルドを実行します。そして、サーバーが動作する6時間ごとではなく、thatの時間にリポジトリのバージョンにタグを付けたいと確信しています。
したがって、「ビルドサーバー」は単なる誤った呼び名であり、実際には「連続テストサーバー」です。そうでなければ、ほとんど役に立たないように聞こえます。
また、ビルドサーバーはエスクローの基盤を提供し、他の人が所有権を取得する権利を持っている場合にビルドを再現するために必要なすべての部分をキャプチャできるようにします。
ビルドサーバーは、リポジトリにある大規模なプロジェクトのコンパイルタスク（夜間ビルドなど）をスケジュールするために使用されます。これは、数時間以上かかる場合があります。
ビルドサーバーは、コードの一種のセカンドオピニオンを取得します。チェックインすると、コードがチェックされます。機能する場合、コードの品質は最低です。
さらに、低レベルの言語は、高レベルの言語よりもコンパイルに時間がかかります。 「さて、私の.Netプロジェクトは数秒でコンパイルされます。大したことは何ですか？」と考えるのは簡単です。しばらく前に、Cコードをいじる必要があり、コンパイルにかかる時間を忘れていました。