ビルドスクリプトの利点は何ですか？

私のプログラミングのキャリアのほとんどで、実行可能なプログラムを作成するために使用しているIDEで「ビルド/コンパイル/実行」コマンドを使用しました。これは1つのボタンで、非常に簡単です。ただし、さまざまな言語やフレームワークについて詳しく知ると、プロジェクトを実行するための「ビルドスクリプト」（ANT、Maven、Gradleなど）の話がどんどん増えています。これらの私の理解は、それらが設定の詳細を指定するコンパイラ/リンカー/魔法のプログラムメーカーへの指示であるということです-細目。

学校に戻ってメイクファイルを書いたことを覚えていますが、そのとき特別な利点はありませんでした（便利な「ビルド」ボタンのあるIDEが存在しないUnixターミナルで書くときにのみ使用しました）。それ以外にも、ビルドスクリプトがプログラムを作成するだけでなく、ホストマシンに関係なくユニットテストを実行し、リソースを保護する方法を説明する他の質問があります。

ビルドスクリプトは開発者として理解することが重要であるという感覚を揺るがすことはできませんが、意味のある説明が欲しいです。なぜビルドスクリプトを使用/作成する必要があるのですか？

Build ScriptとBuild Serverの責任は、より広い範囲での役割について説明しています。IDEの「ビルド/実行」コマンドまたは同様の単​​純なメソッドに対して、ビルドスクリプトが提供する特定の利点を探しています。

オートメーション。

開発中は、最も単純なプロジェクトでのみ、デフォルトの「ビルド」ボタンが必要なすべての処理を行います。APIからWSを作成し、ドキュメントを生成し、外部リソースとリンクし、変更をサーバーにデプロイする必要がある場合があります。一部のIDEでは、追加のステップまたはビルダーを追加してビルドプロセスをカスタマイズできますが、 IDEの商品を通じてビルドスクリプトを生成します。

しかし、システムの開発はコードを書くだけではありません。関係する複数のステップがあります。IDEに依存しないスクリプトは自動的に実行できます。つまり、次のことを意味します。

• バージョン管理への変更をコミットすると、サーバーによって新しいビルドを自動的に起動できます。ビルドに必要なものをコミットすることを忘れていないことを保証します。

• 同様に、ビルドが完了したら、テストを自動的に実行して、何かを壊したかどうかを確認できます。

• 組織の残りの部分（QA、sysadmins）は、

  a）制御バージョンから完全に再現可能です。

  b）それらすべてに共通です。

私が1人のチームとして働いていたとしても、その目的のためにスクリプトを使用しました。修正プログラムを開発したら、SVNにコミットし、SVNを別のディレクトリにエクスポートし、ビルドスクリプトを使用してソリューションを生成します。その後、プリプロダクションシステムに進み、後でプロダクションに行きます。数週間後に（私のローカルコードベースが既に変更されている）誰かがバグに苦情を申し立てた場合、システムを適切にデバッグするためにチェックアウトする必要があるSVNリビジョンを正確に知っていました。

コードと同様に、ビルドスクリプトはコンピューターによって実行されます。コンピュータは、一連の指示に従うのが非常に得意です。実際、（自己修正コードの外で）コンピューターは、同じ入力が与えられると、まったく同じ方法で同じ命令シーケンスを実行します。これにより、コンピュータのみが一致できるレベルの一貫性が実現します。

それとは対照的に、私たちの水で満たされた肉袋は、次のステップに関しては実に卑劣です。その厄介な分析的脳は、それが出くわすすべてのものに疑問を抱く傾向があります。「ああ...私はそれをする必要はありません」、または「このフラグを本当に使用するのですか？ええ...私はそれを無視します。」また、満足する傾向があります。何回か何かをやったら、指示を知っていると信じ始め、指示シートを見る必要はありません。

「実用的なプログラマー」から：

さらに、プロジェクトの一貫性と再現性を確保したいと考えています。手動の手順では、一貫性が変更されます。特に手順の側面が異なる人々による解釈に対して開かれている場合、再現性は保証されません。

さらに、命令を実行するのが非常に遅くなります（コンピューターと比較して）。数百のファイルと構成を持つ大規模なプロジェクトでは、ビルドプロセスのすべてのステップを手動で実行するのに何年もかかります。

実世界の例を挙げましょう。ほとんどのコードがいくつかの異なるハードウェアプラットフォームで共有される組み込みソフトウェアを使用していました。各プラットフォームには異なるハードウェアがありましたが、ほとんどのソフトウェアは同じでした。しかし、各ハードウェアに固有の小さな部分がありました。理想的には、共通部分はライブラリに配置され、各バージョンにリンクされます。ただし、一般的な部分を共有ライブラリにコンパイルすることはできませんでした。さまざまな構成でコンパイルする必要がありました。

最初に、各構成を手動でコンパイルしました。構成を切り替えるのに数秒しかかからず、それほど苦痛ではありませんでした。プロジェクトの終わりに向かって、コードの共有部分に重大な欠陥が発見されました。この部分では、デバイスが基本的に通信バスを引き継ぐことになります。これは悪かった！すごく悪い。コード内のバグを見つけて修正し、すべてのバージョンを再コンパイルしました。1つを除きます。ビルドプロセス中に気が散ってしまい、忘れてしまいました。バイナリがリリースされ、マシンが構築され、1日後、マシンが応答しなくなったという電話がありました。私はそれをチェックアウトし、デバイスがバスをロックしたことを発見しました。「しかし、私はそのバグを修正しました！」。

私はそれを修正したかもしれませんが、その1つのボードに到達することはありませんでした。どうして？なぜなら、すべてのシングルバージョンを1クリックでビルドする自動ビルドプロセスがなかったからです。

あなたがしたいことがすべてである場合<compiler> **/*.<extension>、ビルドスクリプトはほとんど目的を果たしません（ただしMakefile、プロジェクト内にが表示された場合、それでビルドできることがわかっていると主張できますmake）。大事なことは-自明でないプロジェクトは通常それ以上を必要とする-少なくとも、通常はライブラリを追加し、（プロジェクトが成熟するにつれて）ビルドパラメーターを構成する必要があるということです。

通常、IDEは少なくともそのように構成可能ですが、ビルドプロセスはIDE固有のオプションに依存しています。Eclipseを使用している場合、AliceはNetBeansを好み、BobはIntelliJ IDEAを使用したい場合、構成を共有できません。また、ソース管理に変更をプッシュした場合、IDEが作成した構成を手動で編集する必要があります他の開発者のファイル、または他の開発者に通知して、彼らが自分でそれを行うようにします（つまり、IDEの構成がIDEの一部に対して間違っている場合にコミットが行われることを意味します...）。

また、チームが使用する各IDEでその変更を行う方法を把握する必要があり、それらのIDEのいずれかがその特定の設定をサポートしていない場合...

現在、この問題は文化に依存しています-開発者はIDEを選択しないことを受け入れられるかもしれません。しかし、IDEを使用した経験のある開発者は通常、より使いやすく効率的であり、テキストエディターのユーザーはお気に入りのツールについて熱心に熱心になる傾向があるため、これは開発者に自由を与えたい場所の1つです-ビルドシステムを使用すると、まさにそれを実行できます。一部の人々はビルドシステムの好みを持っているかもしれませんが、それはIDE /エディタの好みほど熱狂的ではありません...

すべての開発者が同じIDEを使用するようにした場合でも、ビルドサーバーにそれを使用するよう説得してください。

さて、IDEが優れたGUIを提供する傾向がある、単純なビルドプロセスのカスタマイズ用です。コンパイル前のソースファイルの前処理/自動生成など、より複雑なものが必要な場合は、通常、IDE構成内の基本的なテキスト領域にビルド前スクリプトを記述する必要があります。どの部分のビルドシステムでもその部分をコーディングする必要がありますが、コードを記述する実際のエディターで行うことができます。さらに重要なことは、ビルドシステムのフレームワーク自体がこれらのスクリプトの編成をサポートすることです。

最後に-ビルドシステムは、プロジェクトをビルドするだけでなく、チームの全員が実行する必要がある他のタスクを実行するようにプログラムできます。でRuby on Railsに、例えば、ビルドシステムでこれらのタスクを置くなど、一時ファイルをクリーニングするために、データベースの移行を実行するためのシステムタスクを構築するには、あるチームの全員が一貫して行うことができますことを保証します。

多くのIDEは、何かを構築するために使用されるコマンドをパッケージ化してから、スクリプトを生成して呼び出すだけです！

たとえば、Visual Studioでは、「コマンドライン」ボックスでC ++コンパイルのコマンドラインパラメーターを確認できます。ビルド出力をよく見ると、コンパイルの実行に使用されたビルドスクリプトを含む一時ファイルが表示されます。

現在では、すべてMSBuildですが、それでもIDEによって直接実行されます。

したがって、コマンドラインを使用する理由は、ソースに直行し、更新されたかもしれない、または単に必要のない依存関係のヒープを必要とする仲介者をスキップするからです。継続的インテグレーション（CI）サーバーとして機能します。

さらに、スクリプトは、設計されている通常の開発者向けの手順よりも多くのことを行います。たとえば、ビルド後、バイナリをパッケージ化して特別な場所にコピーしたり、インストーラーパッケージを作成したり、バイナリー上で実行するドキュメントツールを作成したりできます。開発者のマシンでは意味のない多くの異なるタスクがCIサーバーによって実行されるため、これらのすべての手順を実行するIDEプロジェクトを作成できますが、開発者向けのプロジェクトとビルド用の2つのタスクを維持する必要があります。一部のビルドタスク（静的解析など）は、開発者プロジェクトには望ましくない時間がかかる場合があります。

要するに、それは簡単です-必要なすべてのことを行うスクリプトを作成し、コマンドラインまたはビルドサーバー構成でそれを開始するのは迅速かつ簡単です。

make

より覚えやすく、入力しやすい

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

また、プロジェクトには非常に複雑なコンパイルコマンドを含めることができます。ビルドスクリプトには、変更されたものだけを再コンパイルする機能もあります。クリーンビルドを行いたい場合は、

make clean

中間ファイルが作成された可能性のあるすべての場所を記憶しようとするよりも、一度適切に設定すると簡単で信頼性が高くなります。

もちろん、IDEを使用している場合は、ビルドボタンまたはクリーンボタンをクリックするのも簡単です。ただし、単純なテキストコマンドを自動化するよりも、画面上の特定の場所、特にウィンドウが移動するとその場所が移動する可能性がある場合、画面上の特定の場所へのカーソルの移動を自動化するのははるかに困難です。

他にどうしますか？他の唯一の方法は、1つの長いコマンドラインコマンドを指定することです。

もう1つの理由は、メイクファイルがインクリメンタルコンパイルを許可するため、コンパイル時間が大幅に短縮されることです。

Makefileは、クロスプラットフォームのビルドプロセスを作成することもできます。CMakeは、プラットフォームに基づいてさまざまなビルドスクリプトを生成します。

編集：

IDEを使用すると、特定の方法に縛られます。多くの人々は、多くのIDEのような機能を持っていなくても、vimまたはemacsを使用します。彼らは、これらの編集者が提供する力を望んでいるので、そうします。IDEを使用していない人にはビルドスクリプトが必要です。

IDEを使用している人でも、何が起こっているのかを本当に知りたいと思うかもしれません。そのため、ビルドスクリプトは、GUIアプローチにはない実装の詳細を提供します。

IDE自体もしばしば内部的にビルドスクリプトを使用します。実行ボタンは、makeコマンドを実行する別の方法にすぎません。

上記の回答は多くの優れた根拠を網羅していますが、追加したい実例（カルマがないためコメントとして追加できない）は、Androidプログラミングのものです。

私はプロのAndroid / iOS / Windows Phone開発者であり、GoogleサービスAPI（主にGoogleマップ）をよく使用しています。

Androidでは、これらのサービスを使用するには、キーストア、または自分が自分だと言う人であることをGoogleに伝える開発者IDファイルのタイプを開発者コンソールに追加する必要があります。アプリが別のキーストアでコンパイルされている場合、アプリのGoogleマップセクションは機能しません。

とにかく実際にアプリの更新に使用できるのはそのうちの1つだけである開発者コンソールに12個のキーストアを追加および管理する代わりに、このキーストアを安全なリポジトリに含め、Gradleを使用して、ビルド時に使用するキーストアをAndroid Studioに正確に伝えます「デバッグ」または「リリース」。これで、Google開発者コンソールに2つのキーストアを追加するだけで、1つは「デバッグ」用、もう1つは「リリース」用になり、チームメンバー全員がリポジトリにクローンを作成して、開発者にアクセスすることなく開発を開始できますコンソールを開き、特定のキーストアのSHAハッシュを追加するか、さらに悪いことに、私はそれらを管理します。これには、各チームメンバーに署名キーストアのコピーを提供するという追加の利点があります。つまり、私が不在で更新がスケジュールされている場合、チームメンバーは、更新。

このようなビルドの自動化は、ビルドの一貫性を維持し、新しい開発者、新しいマシン、またはマシンのイメージを再作成する必要がある場合のセットアップ時間を短縮することにより、技術的な負担を軽減します。

ビルドスクリプトの利点：

• 変更はコードのように見えます（たとえば、git diffコマンドの場合）。ダイアログの異なるチェックオプションのようには見えません。

• 単純なビルドよりも多くの出力を作成する

以前のプロジェクトのいくつかで、ビルドスクリプトを使用して次のことを行いました。

• プロジェクトドキュメントの生成（doxygenベース）
• 建てる
• 単体テストを実行する
• 単体テストのカバレッジレポートを生成する
• バイナリをリリースアーカイブにパックする
• 内部リリースノートを生成します（「git log」メッセージに基づいて）
• 自動テスト

多くの場合、「ビルド」ボタンを自動化された方法で呼び出すことができます（たとえば、Visual Studioはコマンドライン引数を受け入れます）。ビルドボタンでは提供できないものが必要になるとすぐに、ビルドスクリプトを記述します。

たとえば、ほとんどのIDEでは、一度に1つのプラットフォームしか構築できません。または、一度に1つの言語のみ。それから、ビルドされた出力で何をするかがあります：IDEはそれらをすべてインストールパッケージにロールアップできますか？