このページでは、ビルドシステムの概要、機能、役立つ理由について説明します。 コンパイラとビルド スクリプトが開発環境に最適ではない理由 スケールし始めますインフラストラクチャがあまりない 構築経験を積むことです
ビルドシステムとは
基本的に、すべてのビルドシステムには、 エンジニアがソースコードを実行可能なバイナリに書き、そのバイナリを読み取れるようにする 学習します。ビルドシステムは、人が作成するコードだけのものではありません。また ビルドを自動的に作成できます。テストやリリース用のマシンが できます。数千人のエンジニアがいる組織では ほとんどのビルドは、エンジニアが直接トリガーするのではなく、自動的にトリガーされます。
コンパイラだけではいけませんか？
ビルドシステムの必要性はすぐにはわかりません。ほとんどのエンジニア
コーディングの学習中にビルドシステムを使用しない: ほとんどのケースは、まずツールを呼び出すことから始めます。
gcc や javac をコマンドラインから直接使用することも、
統合開発環境（IDE）です。すべてのソースコードが Google Cloud に
その場合、次のようなコマンドで問題ありません。
javac *.java
これは Java コンパイラに対し、現在のディレクトリにあるすべての Java ソースファイルを バイナリ クラスファイルに変換します。最も単純なケースでは ご利用いただけます。
しかし、コードが拡張されるとすぐに複雑化が起こります。javac さんはスマートです
現在のディレクトリのサブディレクトリを調べて、
インポートします。しかし、インフラストラクチャの他の部分に保存されたコードを見つける方法はない。
filesystem（複数のプロジェクトで共有されているライブラリなど）。また、特徴量は
詳しく見ていきます。大規模なシステムでは、多くの場合、ソフトウェアで作成されたさまざまな部分が
さまざまなプログラミング言語と、その依存関係が網羅されている
つまり、1 つの言語のコンパイラがシステム全体を構築することはできません。
複数の言語のコードや複数のコンパイル コードの構築は、もはや 1 ステップのプロセスではなくなりました。次に、クラウド コンピューティングと コードはこれらの要素に依存しており、必要に応じて ツールセットが異なるからです依存関係が変更された場合は、 このプロセスを繰り返して、古いバイナリへの依存を回避してください。均等なコードベースで このプロセスはすぐに手間がかかり、エラーが発生しやすくなります。
また、コンパイラは、外部 IP アドレスを
などの依存関係（Java のサードパーティの JAR ファイルなど）が含まれます。ビルドシステムを使用しない場合は
インターネットから依存関係をダウンロードし、
ハードドライブの lib フォルダに配置し、コンパイラが、
そのディレクトリから抽出できます。時間の経過とともに
更新、バージョン、ソースを管理できます。
シェルスクリプトについてはどうでしょうか
趣味のプロジェクトは、すぐにそれを構築できるほどシンプルなものだとします。 それでも 前述の問題に直面し始め 使用します。まだビルドシステムは必要ないと思っている方も 簡単なシェル スクリプトを使用して、面倒な部分を 正しい順序で並べることです。しばらくは役に立ちますが、 すぐにより多くの問題にぶつかり始めます
この作業は面倒になります。システムが複雑になるにつれ ビルド スクリプトで作業する作業は、実際のコード作業に費やす時間とほぼ同じです。デバッグ シェル スクリプトは手間がかかり、数多くのハッキングが階層化されて 相互に通信します。
処理に時間がかかります。古いライブラリに誤って依存しないようにするため、 ビルドスクリプトですべての依存関係を 順番どおりにビルドし 実行します。どの部分が必要かを検出するためのロジックを 非常に複雑になり、スクリプトでエラーが発生しやすいものになります。または 毎回再構築が必要な部分を指定することを 検討します 最初のセクションに戻ります
このたび、リリースの時期になりましたのでお知らせいたします。すべての引数を解読した方がよい 最終ビルドを作成するために jar コマンドに渡す必要があります。また、 中央リポジトリに push できますまた、 ドキュメントの更新をプッシュし ユーザーに通知を送信しますうーん、 別のスクリプトが必要になるかもしれない...
みなさんにハードドライブがクラッシュしたため、サーバー全体を再作成する必要が ありませんすべてのソースファイルを 1 つのバージョンに ダウンロードしたライブラリについてはどうでしょうか探してください 元のバージョンと同じバージョンを ダウンロードしましたか？スクリプトは、使用する特定のツールに あるかもしれません。その同じ環境を復元して、 どうなるでしょうか環境変数を設定した どうやってコンパイラがうまく機能してくれて、それを忘れてしまえばよいのでしょうか？
問題はあるものの、プロジェクトは十分に成功しており、次のことを行えるようになりました。 エンジニアの増員を開始しますこうして Google Cloud Platform の 同じ苦痛なプロセスを経て、 新しいデベロッパーがチームに加わるたびに、ブートストラップ プロセスを開始します。そして 最善の努力をしても、それぞれにわずかな違いがある 保護します。多くの場合、一人のパソコンで機能するものは機能しない デバッグツールパスやデバッグツールの 違いはどこにあるかを調べます。
あなたは、ビルドシステムを自動化する必要があると判断しました。理論的には、これは 新しいパソコンを入手してビルドを実行するための設定を行うだけ 毎晩 cron を使用してスクリプトを実行します。やはり難しいところを経て 人間の脳をトレーニングするという利点は 軽微な問題を検出して解決できるようにしています毎朝、オフィスに 昨夜のビルドが失敗したのは 昨日の開発者が 自動化されたソリューションには機能しなかった 使用します。どれも一つの単純な修正ですが、しばしば起こります。 毎日多くの時間を費やして、これらのシンプルな あります。
プロジェクトが大きくなるにつれて、ビルドの速度が遅くなります。ある日、待っている間に ビルドが完了するまでに アイドル状態のデスクトップを悲しみながら 同僚は休暇中であり、Google Workspace を 無駄な計算能力もなくなります。
スケーリングという古典的な問題に遭遇しました。1 人の開発者が 数百行のコードしか記述できず（1 ～ 2 週間で 経験を積んだばかりの若手デベロッパーも 必要なのはコンパイラだけです。スクリプトを使用すると、 できます。しかし、複数の開発者とチーム間で調整が必要になり次第、 完璧なビルド スクリプトだけでは十分とは言えません。なぜなら、 マシンのわずかな違いを説明するのは困難ですこの時点で このシンプルなアプローチは実に難しいため、次は実際のビルドシステムに投資しましょう。