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

自動化。

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

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

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

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

• これで、組織の残りの部分（QA、sysadmins）には、コントロールバージョンからだけで完全に再現可能な

  a）ビルドされた製品があります。

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

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

コメント

• これが私見のベストアンサーです。誰もが自分の考えに賛成ですが、これは本当にスクリプトをビルドする理由を示しています。プロジェクトの拡張に伴って進行する自動化をサポートしているため、時間を大幅に節約できます。
• @Alexus時間だけでなく、ばかげた間違いもあります。 ;）”繰り返しは退屈につながります。退屈は恐ろしい間違いにつながります。恐ろしい間違いは、’私がまだ退屈していることを望みます。’ “（時間内にばかげた間違いを測定することもできますが、’ s ‘は、いくつかの原因から時間を節約できることを理解することが重要です。）
• 1人のプロジェクトの場合でも、ローカルのJenkinsサーバーを実行して

  別のディレクトリにビルドする”が役立ちます。 ‘ Windowsでクロスコンパイルも確認する必要があるものに取り組んでいるので、Jenkinsにテストをビルドして実行させてから、クロスコンパイルされたバージョンをビルドすると、はるかに自信が持てるようになります（もちろん、効率的です！）バグ修正をリリースする必要がある場合。

• ‘再現可能なビルドの議論に同意しません。今日のビルドシステムには制御されていない変数が非常に多いため、再現可能なビルドを取得するのはかなり困難です。あなたの議論は、すぐに使えるようになるように思えますが、これはまったく真実ではありません。
• @JonasGr ö ger Automationは、最大の変数：人間。

コードと同様に、ビルドスクリプトはコンピューターによって実行されます。コンピュータは、一連の指示に従うのが非常に優れています。実際、（自己変更コード以外では）コンピューターは、同じ入力が与えられた場合、まったく同じ方法で同じ一連の命令を実行します。これにより、コンピュータだけが対応できるレベルの一貫性が実現します。

対照的に、私たちの水で満たされたフレッシュバッグは、次の手順に関してはまったく卑劣です。その厄介な分析脳は、遭遇するすべてのものに疑問を投げかける傾向があります。 「ああ…私はそれをする必要はない」または「私は本当にこのフラグを使用するのですか？ええと…私は「無視します」さらに、私たちは自己満足する傾向があります。 「数回何かをした後、私たちは指示を知っていると信じ始め、指示シートを見る必要はありません。

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

さらに、プロジェクトの一貫性と再現性を確保したいと考えています。手動の手順では、一貫性を変更することができます。再現性は保証されていません。特に、手順の側面がさまざまな人に解釈される可能性がある場合はそうです。

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

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

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

私はそれを修正したかもしれませんが、それはその1つのボードにその方法を見つけることができませんでした。どうして？ 1クリックですべてのバージョンをビルドする自動ビルドプロセスがなかったためです。

コメント

• そして、コーヒーを飲みに行くことができます。ビルドスクリプトが実行されています！

やりたいことが、ビルドスクリプトはほとんど目的を果たしません（ただし、プロジェクトにMakefileが表示されている場合は、）。重要なのは、重要なプロジェクトには通常それ以上のものが必要です。少なくとも、通常はライブラリを追加し、（プロジェクトが成熟するにつれて）ビルドパラメータを構成する必要があります。

IDEは通常、少なくとも構成可能ですが、ビルドプロセスはIDE固有のオプションに依存しています。 Eclipse を使用している場合、アリスは NetBeans を好み、ボブは

多くの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を使用すると、増分コンパイルが可能になり、コンパイル時間が大幅に短縮されます。

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

編集：

IDEを使用すると、特定の方法に縛られます。多くの人は、IDEのような機能はあまりありませんが、vimやemacsを使用します。これらの機能が必要なために使用します。エディターが提供します。IDEを使用していない場合はビルドスクリプトが必要です。

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

IDE自体は、内部でもスクリプトを作成することがよくあります。実行ボタンは、makeコマンドを実行するもう1つの方法です。

上記の回答は、多くの良い根拠をカバーしています。しかし、私が追加したい（カルマがないためコメントとして追加できない）実際の例の1つは、Androidプログラミングからのものです。

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

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

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

このようなビルドの自動化により、ビルドの一貫性が保たれ、新しい開発者や新しいマシンを入手したとき、またはイメージを再作成する必要があるときのセットアップ時間が短縮されるため、技術的負債が削減されます。機械。

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

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

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

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

• プロジェクトドキュメントの生成（酸素ベース）
• ビルド
• 単体テストを実行する
• 単体テストのカバレッジレポートを生成する
• バイナリをリリースアーカイブにパックする
• 内部リリースノートを生成する（「gitlog」メッセージに基づく） ）
• 自動テスト

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

たとえば、ほとんどのIDEではビルドのみが可能です。一度に1つのプラットフォームまたは1つだけ一度に言語。次に、ビルドされた出力で何をしますか。IDEはそれらをすべてインストールパッケージにまとめることができますか？