専用ビルドマシンの目的は何ですか？

前回のビルドサイクルが不十分な展開につながる多くの状況のた​​め、私はオフィスでキャンペーンを行い、専用のビルドマシンを使用して将来のすべての展開を実行し、上司はこの提案を受け入れました。

ただし、オフィスで実際のマシンを使用する代わりに、1台のマシンを他の複数のグループと共有する必要があります。また、必要な情報をすべて入力してオフィスを出て階段を降りる手間がかかります。単純なビルドを実行するためだけに別のオフィスに移動することは、なぜ私が最初にこれを提案したのか疑問に思います。

別個のビルドマシンを使用するというアイデアは、元々、自分のローカルで記述されたコードを他の複数の開発者のコ​​ードから分離し、マシン上にあったハイジャックされたファイルを展開から分離することでした。また、ClearCaseファイル管理システムに対する懸念の高まりを解決することも目的でした。これは、「依存関係がある」別のアクティビティも含めない限り、特定のビルドアクティビティの展開を拒否することがよくあります。

実際にこのプロセスを進めているので、ビルドマシンを使用する目的全体を誤解していないかどうか、そしてこのマシンをテスト、ステージング、および実稼働環境へのコード展開にのみ使用しているため、私たちの個人的な開発者テストの展開ではなく、それが何らかの目的に役立つかどうかはわかりません。

それでは、ビルドマシンを使用する実際の理由は何ですか？また、正しく使用することに近づいていますか？

通常、専用のビルドマシンがあるだけでなく、その専用マシンでビルドサーバーを実行します。専用のビルドマシンは、開発者の作業をブロックせず、集中型マシンから展開するという利点を提供するだけです。

ビルドサーバーにはさらに多くの機能があります。ビルドサーバーはCI（継続的インテグレーション）を許可します。つまり、VCSへのプッシュ（gitなど）ごとに自動的にビルドされ、ユニットテストがあればそれを実行し、「ワンクリック展開」を可能にします。ビルドサーバーは、ビルドまたはテストが失敗した場合、メールごとに通知できます。過去のデータと何が起こったかのトレンドを提供します。

通常、ビルドサーバーには、ブラウザーで実行されるWeb GUIを使用して、複数のユーザーまたはチームが一度にアクセスできます。

Javaの世界で最も使用されているビルドサーバーの1つはJenkinsです。JenkinsはC ++ビルドでも問題なく動作します（これら2つの言語を使用しているようです）。Jenkinsは、プログラミングや構築に関連する必要のないあらゆる種類のタスクを実行できるため、自動化サーバーと呼ばれます。

Traubenfuchsの答えに加えて、質問でビルドマシンを使用する別の理由を示唆しています。

ソフトウェアは上に構築という理由だけで、あなたのマシン、それが他人の上に構築することを意味するものではありません。マシン上にたまたまある（そしてバージョン管理下にない）ランダムなファイルに依存しているかもしれません。不明なビルドスクリプトから呼び出される、忘れられたアプリケーションまたはライブラリに依存している可能性があります。

専用のビルドマシンがある場合は、そのマシンに何がインストールされているかを知っておく必要があります。これは十分に文書化する必要があります。おそらく数年後、ソフトウェアを再構築する必要がある場合、文書化されたものをインストールした新しいビルドマシンを作成するだけで十分です。

専用のビルドマシンを使用する主な理由は、誰がビルドを行っているかに関係なく、一貫したビルドを取得するためです。開発者のワークステーションが同一になることはめったにありません。各ビルドが依存関係やコンパイラなどとまったく同じバージョンを使用していることを知るのは困難です。開発ワークステーションビルドの最悪の問題の1つは、開発者がバージョン管理にチェックインされていないコードからビルドできることです。

使用しているプラ​​ットフォーム/言語は明確ではありませんが、理想的には、ソース管理から直接プルするビルドサーバーが必要です。つまり、ビルドが必要な場合、リポジトリの特定のバージョンからソースを取得し、自動的にコンパイルします。これには、ビルドをスクリプト化するための自動ビルドツールの使用が必要です。これがない場合は、ステップ1になります。

開発用にローカルにビルドしても問題はないことに注意してください。ローカルで単体テスト、コード品質分析、ビルドスクリプトの修正を実行する必要があります。そうでなければ、あなたは多くの時間を無駄にします。ビルドサーバーの出力は、本番環境に移行する可能性のあるすべてのものです。統合テストや受け入れテストなどのすべてのQAアクティビティは、ビルドサーバーからのビルドでのみ実行する必要があります。

他の答えは、ビルドを自動化する必要があることを非常に正確に指摘しています。つまり、別のオフィスに行く必要はありません。ただし、ビルドプロセスを改善するために実行できるいくつかの手順を提案させてください。

• まず、ビルドサーバーへのリモートアクセスを設定します。「make」コマンドを入力して手動でビルドする場合、これは「make」と入力するために別のオフィスに移動する必要がないことを意味します。ビルドサーバーにSSHで入力し、「make」と入力します。makeまたは類似のビルドシステムをまだ使用していない場合は、そのようなビルドシステムを使用してください。
• 第二に、バージョン管理システムから最新の変更を自動的にプルする継続的統合環境をインストールし（バージョン管理システムがありますか？そうでない場合、それは追加のステップになります）、ビルドします。私はジェンキンスをお勧めします。ユニットテストとシステムレベルの統合テストも実行するようにJenkinsを設定します（両方がありますか？そうでない場合は、ユニットテストから始めて、システムレベルの統合テストまでを作成します）。
• 第3に、同じマシンを他のチームと共有するのに問題がある場合（使用するオペレーティングシステム、使用するバージョンおよびビット数について意見が異なる場合など）、仮想化の使用を検討してください。今日の優れたサーバーは、膨大な数の仮想マシンを実行できます。おそらく、ビルドが両方のアーキテクチャで動作することがわかるように、32ビットマシンと64ビットマシンをセットアップすることができます。
• 最後に、これは必要ではないかもしれません：アプリケーションのパフォーマンスが非常に重要で、同時に実行される他のビルド/テスト実行が結果に大きく影響する場合など、絶対に専用マシンが必要な場合は、専用のハードウェアサーバーをインストールしますあなただけが使用します。ただし、40個以上の仮想CPUコアを備えた最近のサーバーでは、同じCPUコアへのアクセスを共有しない少数の仮想マシンを作成するのは比較的簡単です。

共有マシンは、手動ビルドよりもはるかに優れていると考えています。現在のプロジェクトでは仮想マシンを使用していますが、システムレベルの統合パフォーマンステストが必要なため、40の仮想CPUコアを備えた専用サーバーに移行しています。

...オフィスの実際のマシンを使用する代わりに、1台のマシンを複数の他のグループと共有する必要があります...

あなたはそれが悪いことのように言う。

これで、すべてのビルド（あなたと他のチーム）がビルドされる共通のビルドサーバーができました。ビルドの一貫性？小切手。

...必要なすべての情報を自分のオフィスから出て、簡単なビルドを実行するために階段を降りて別のオフィスに移動しなければならないという面倒なことは、なぜこれを最初に提案したのか疑問に思います。

あなたはまだ手動でビルドを実行していますが、それは良くありません。

あなたに代わって行われるビルドのリクエストを送信/キューイングし、そのプロセスに結果を送り返すサーバープロセスが必要です。

他の関連する答えに加えて、問題のマシンでビルドを直接実行しているようにも聞こえます。

信頼性の高いビルドシステム、特にビルドマシンを他のユーザーと共有する場合、仮想マシン内でビルドを実行するのが普通です。これにより、コードが依存する独自のバージョンのアプリケーションまたはライブラリをインストールすることにより、他のユーザーがビルドの動作を変更できなくなります。これの大きな利点は、VMを簡単にバックアップでき、他のPC（開発マシンを含む）に簡単にクローンできることです。

IDE、OS、個々の開発者のライブラリ構成に関係なく、ビルドを実行するための一元化された中立的な場所を提供します。

専用のビルドマシンを使用すると、リポジトリにコードがプッシュされるたびにビルドマシンを再構築できます。誰かがビルドを中断すると、プロセスはすぐにアラートを送信して、問題をすぐに修正できます。

すべての再現性と信頼性を高め、依存関係の問題が潜んでいるリポジトリが壊れたゴミで一杯にならないようにすることに加えて、マシンでビルドを動作させるために必要なことは何でもコピーするだけなので、開発者の生活が楽になりますビルドマシンで行われています。