専用ビルドマシンの目的は何ですか？
前回のビルドサイクルが不十分な展開につながるさまざまな状況により、私は専用のビルドマシンで将来のすべての展開を実行するように私たちのオフィスでキャンペーンを行い、上司がこの提案を受け入れました。
ただし、オフィスで実際のマシンを使用する代わりに、1台のマシンを他のいくつかのグループと共有する必要があります。また、必要な情報をすべてオフィスから出て、階段を降りる必要がありました。単純なビルドを実行するためだけに別のオフィスに行くと、なぜこれを最初に提案したのか不思議に思います。
個別のビルドマシンを用意するという考えは、元々、ローカルで記述した独自のコードを他の数人の開発者のコードから分離し、マシン上にあるハイジャックされたファイルをデプロイメントから分離することでした。また、ClearCaseファイル管理システムで懸念が高まっていることを解決するためにもありました。このシステムは、「依存関係がある」別のアクティビティも含めない限り、特定のビルドアクティビティのデプロイを拒否することがよくあります。
実際にこのプロセスを進めているので、ビルドマシンを使用する目的全体を誤解しているかどうかを疑問に思っています。このマシンは、テスト、ステージング、および本番環境へのコードのデプロイメントにのみ使用しているためです。私たちの個人的な開発者テストの展開ではなく、それが何らかの目的に役立つかどうかはわかりません。
では、ビルドマシンを使用する実際の理由は何ですか。また、それを正しく使用するようになったことがありますか？
通常、専用のビルドマシンだけでなく、その専用マシンでビルドサーバーを実行することもできます。専用のビルドマシンは、開発者の作業を決してブロックせず、集中型マシンからデプロイするという利点を提供するだけです。
ビルドサーバーはさらに多くを提供します。ビルドサーバーはCI（継続的インテグレーション）を可能にします。つまり、VCSへのすべてのプッシュ（gitなど）で自動的にビルドされ、ユニットテストがあれば実行し、「ワンクリックデプロイメント」を可能にします。ビルドまたはテストが失敗した場合、ビルドサーバーはメールごとに通知できます。彼らは過去のデータと何が起こったかの傾向を提供します。
ビルドサーバーは通常、ブラウザーで実行されるWeb GUIを使用して、複数のユーザーまたはチームが一度にアクセスできます。
Java世界で最も使用されているビルドサーバーの1つはJenkinsです。JenkinsはC++ビルドでも完全に正常に動作します（これら2つの言語を使用しているように思われるため）。Jenkinsは、自動化サーバーを呼び出します。プログラミングやビルドに関連する必要のないあらゆる種類のタスクを実行できます。
Traubenfuchsの回答に加えて、ビルドマシンの別の理由についても質問されました。
ソフトウェアがyourマシンで構築されているからといって、それが他の誰かのマシンで構築されることを意味するものではありません。あなたはたまたまあなたのマシン上にあるランダムなファイルに依存しているかもしれません（そしてバージョン管理下にないかもしれません）。不明なビルドスクリプトから呼び出される、忘れられたアプリケーションまたはライブラリに依存している可能性があります。
専用のビルドマシンがある場合、何がインストールされているかを知っている必要があります。これは十分に文書化する必要があります。ソフトウェアを再構築する必要がある場合、おそらく数年後、文書化されたものがインストールされた新しいビルドマシンを作成するだけで十分です。
専用のビルドマシンを用意する主な理由は、誰がビルドを行っているかに関係なく、一貫したビルドを取得するためです。開発者のワークステーションが同一である（めったにない）ことはめったにありません。各ビルドが同じバージョンの依存関係やコンパイラなどを使用していることを知るのは困難です。開発ワークステーションビルドの最悪の問題の1つは、開発者がバージョン管理にチェックインされていないコードからビルドできることです。
どのプラットフォーム/言語を使用しているかは明確ではありませんが、理想的には、ソース管理から直接プルするビルドサーバーが必要です。つまり、ビルドが必要な場合、指定されたバージョンのリポジトリからソースを取得し、自動的にコンパイルします。これには、ビルドをスクリプト化するために自動ビルドツールを使用する必要があります。これがない場合は、それがステップ1です。
開発用にローカルでビルドすることには何の問題もないことに注意してください。ローカルで実行する単体テスト、コード品質分析、およびビルドスクリプトのホーニングを確実に行う必要があります。そうでなければ、あなたは多くの時間を無駄にするでしょう。ビルドサーバーの出力は、本番環境に移行する可能性があるすべてのものです。統合や受け入れテストなどのすべてのQAアクティビティは、ビルドサーバーからのビルドでのみ実行する必要があります。
他の答えは、ビルドを自動化する必要があることを正確に示しています。つまり、別のオフィスに行く必要はありません。ただし、ビルドプロセスを改善するために実行できるいくつかのステップを提案します。
- まず、ビルドサーバーへのリモートアクセスをセットアップします。コマンド「make」を入力して手動でビルドする場合、これは、「make」と入力するために別のオフィスに行く必要がなくなり、ビルドサーバーにSSHで接続して「make」と入力するだけでよいことを意味します。 makeまたは同様のビルドシステムをまだ使用していない場合は、そのようなビルドシステムを使用してください。
- 次に、バージョン管理システムから最新の変更を自動的にプルし（そうでなければバージョン管理システムがありますね。そうでなければ追加の手順になります）、それらをビルドする継続的統合環境をインストールします。私はジェンキンスをお勧めします。ユニットテストとシステムレベルの統合テストも実行するようにJenkinsを設定します（両方ありますか？そうでない場合は、ユニットテストから始めて、システムレベルの統合テストまで作成します）。
- 第3に、同じマシンを他のチームと共有することに問題がある場合（使用するオペレーティングシステム、使用するバージョンやビット数について異なる意見がある場合など）、仮想化の使用を検討してください。今日の優れたサーバーは、膨大な数の仮想マシンを実行できます。おそらく、32ビットマシンと64ビットマシンをセットアップして、両方のアーキテクチャでビルドが機能することを確認できます。
- 最後に、これは必要ない場合があります。アプリケーションのパフォーマンスが非常に重要で、同時に実行される他のビルド/テスト実行が結果にあまりにも影響を与える場合など、専用のマシンが絶対に必要な場合は、専用のハードウェアサーバーをインストールします。あなただけが使う。ただし、40以上の仮想CPUコアを備えた最近のサーバーでは、同じCPUコアへのアクセスを共有しないいくつかの仮想マシンを作成することは比較的簡単です。
共有マシンは手動ビルドよりもはるかに優れていると思います。現在のプロジェクトでは仮想マシンを使用していますが、システムレベルの統合パフォーマンステストが必要なため、パフォーマンステストに17が必要な40の仮想CPUコアを備えた専用サーバーに移行しています。
...オフィスの実際のマシンを使用する代わりに、1台のマシンを他のいくつかのグループと共有する必要があります...
あなたはそれが悪いことだと言っています。
これで、すべてのビルド（自分のものと他のチームのもの）が構築される共通のビルドサーバーができました。ビルドの整合性？小切手。
...必要なすべての情報をオフィスから出て、簡単なビルドを実行するために別のオフィスに階段を降りる必要があるという煩わしさが、私がこれを最初に提案した理由を不思議に思っています。
あなたはまだビルドを実行しています手動そしてそれは良くありません。
あなたに代わって行われるビルドのリクエストを送信/キューに入れるサーバープロセスが必要であり、そのプロセスに結果を送り返させます。
他の関連する回答に加えて、問題のマシンで直接ビルドを実行しているようにも聞こえます。
信頼できるビルドシステムの場合、特にビルドマシンを他のユーザーと共有する場合は、仮想マシン内でビルドを実行するのが普通です。これにより、コードが依存する独自のバージョンのアプリケーションまたはライブラリをインストールして、他のユーザーがビルドの動作を変更できないようにすることができます。これの大きな利点は、VMを簡単にバックアップできること、および他のPC（独自の開発マシンを含む）に簡単に複製できることです。
これは、個々の開発者のIDE、OS、ライブラリ構成に関係なく、ビルドを実行するための一元的な中立的な場所を提供します。
専用のビルドマシンを使用すると、コードがリポジトリにプッシュされるたびに再ビルドできます。誰かがビルドを中断すると、プロセスはすぐにアラートを送信して、問題をすぐに修正できるようにすることができます。
すべてをより再現可能で信頼性の高いものにし、依存関係の問題が潜んでいるリポジトリが壊れたゴミでいっぱいにならないようにすることに加えて、ビルドを自分のマシンで機能させるために行う必要があるのは何でもコピーするだけなので、開発者の作業が楽になりますビルドマシンで行われています。