ビルドツールとは何ですか？

過去4年間、私はEclipse（Javaの場合）とVisual Studio Express（C＃の場合）でプログラミングしてきました。前述のIDEは、プログラマが要求する可能性のあるすべての機能を提供しているように見えました（もちろん、プログラミングに関連しています）。

最近、「ビルドツール」と呼ばれるものについて聞いています。彼らはほとんどあらゆる種類の現実世界の開発で使用されていると聞きました。彼らは正確には何ですか？彼らはどのような問題を解決するように設計されていますか？なぜ過去4年間にそれらを必要としなかったのですか？それらは、IDEを取り除いたコマンドラインのようなものですか？

ビルドツールとは何ですか？

ビルドツールは、ソースコードから実行可能なアプリケーションの作成を自動化するプログラムです（例：androidアプリの.apk）。ビルドは、コードをコンパイル、リンク、およびパッケージ化して、使用可能な形式または実行可能な形式に組み込みます。

基本的にビルドの自動化は、ソフトウェア開発者が以下のような日常の活動で行うさまざまなタスクをスクリプト化または自動化する行為です。

1. 依存関係のダウンロード。
2. ソースコードをバイナリコードにコンパイルします。
3. そのバイナリコードをパッケージ化します。
4. テストを実行しています。
5. 本番システムへの展開。

なぜビルドツールやビルドオートメーションを使用するのですか？

小規模なプロジェクトでは、開発者がビルドプロセスを手動で呼び出すことがよくあります。これは、ビルドする必要のあるもの、ビルドの順序と依存関係を追跡することが非常に難しい大規模なプロジェクトでは実用的ではありません。自動化ツールを使用すると、ビルドプロセスの一貫性が向上します。

利用可能なさまざまなビルドツール（命名はごくわずか）：

1. Javaの場合-Ant、Maven、Gradle。
2. .NETフレームワーク-NAnt
3. c＃-MsBuild。

詳細については、次のリンクを参照してください。

1. 自動化を構築する

2. ビルド自動化ソフトウェアのリスト

ありがとう。

ビルドツールは、ビルドを管理および整理するためのツールであり、特に相互接続されている場合に、多くのプロジェクトがある環境では非常に重要です。彼らは、さまざまな人々がさまざまなプロジェクトに取り組んでいるところで、何も壊さないようにするのに役立ちます。そして、あなたがあなたの変更をするとき、彼らは何も壊さないことを確実にするために。

これまで聞いたことがないのは、これまで商業環境で働いたことがないためです。特にソフトウェアハウスで作業している場合は、商業環境内で遭遇することはおそらくないであろう多くのものがあります。

他の人が言ったように、あなたはそれらを使用してきましたが、おそらく通常の商業的な作業方法とは異なる方法で作業していたので、それらを考慮する必要はありませんでした。

ビルドツールは通常、IDE内またはIDEから完全に独立したコマンドラインで実行されます。

アイデアは、コードのコンパイルとパッケージ化の作業を、作成、デバッグなどから分離することです。

ビルドツールは、コマンドまたはIDE内で実行でき、どちらもユーザーがトリガーします。また、コードをリポジトリからチェックアウトしてクリーンビルドマシンにチェックインした後、継続的インテグレーションツールで使用することもできます。

makeは、* nix環境でC / C ++をビルドするために使用された初期のコマンドツールです。

Java開発者として、最も人気のあるビルドツールはAntとMavenです。どちらもIntelliJ、Eclipse、NetBeansなどのIDEで実行できます。また、Cruise ControlやHudsonなどの継続的インテグレーションツールでも使用できます。

ビルドツールは通常、ソースコードをバイナリに変換するものです。ソースコードを整理し、コンパイルフラグを設定し、依存関係を管理します。それらの一部は、ユニットテストの実行、静的分析の実行、ドキュメントの生成にも統合されます。

EclipseまたはVisual Studioもビルドシステムです（ただし、IDEがより多くなります）。VisualStudioでは、内部でVisual Studioプロジェクトファイルを解析するための基礎となるmsbuildです。

すべてのビルドシステムの起源は、有名な「make」のようです。

異なる言語用のビルドシステムがあります。

1. C ++：make、cmake、premake
2. Java：ant + ivy、maven、gradle
3. C＃：msbuild

通常、適切なドメイン固有の言語（make、cmake）またはxml（ant、maven、msbuild）を使用してシステムをビルドし、ビルドを指定します。現在の傾向は、実際のスクリプト言語を使用して、ビルドスクリプトを作成することです（たとえば、premakeにはlua、gradleにはgroovy）。スクリプトを使用する利点は、柔軟性がはるかに高く、標準のセットを思い付くことができることです。 API（ビルドDSLとして）。

ビルドプロセスは、いくつかのビルドツールを使用してエラーがないようにソースコードをコンパイルし、ビルド（プロジェクトの実行可能バージョン）を作成するプロセスです。私たち（主に開発者）は、ソースコードにいくつかの変更を加え、そのコードをチェックインして、ビルドプロセスを実行します。ビルドプロセスの後、2つの結果が得られます。1.ビルドパスと、プロジェクトの実行可能バージョンを取得します（ビルドの準備ができています）。2.失敗して特定のエラーが発生し、ビルドが作成されません。

ビルドプロセスには次のような種類があります。1.ナイトリービルド2.ゲートビルド3.継続的インテグレーションビルドなど。

ビルドツールは、ビルドの作成プロセスを支援および自動化します。

* つまり、Short Buildは、開発者または開発チームが製品を継続的に監視し、開発プロセスの早い段階で問題を解決することにより、製品の最終結果に対する信頼を得るために使用するプレリリース形式のソフトウェアのバージョンです。*

これらは、ビルドを完了するためのさまざまなタイプのプロセスです。

1.継続的インテグレーションビルド：これは主に開発者がコードをチェックインし、チェックインの直後にビルドが最近の変更のビルドを開始するため、開発者が行った変更がチェックインの直後に機能したかどうかを知る必要があります。これは、小規模なプロジェクトまたはプロジェクトのコンポーネントに適しています。複数のチームがプロジェクトに関連付けられている場合、または大きなチームが存在する場合。同じプロジェクトに取り組んでいる開発者の場合、このシナリオはあたかも「いいえ」がないかのように処理することが困難になります。チェックインとビルドが特定の時点で失敗した場合、すべての破損が1つの問題が原因で発生したのか、複数の問題が原因で発生したのかを追跡することは非常に困難になります。その変更後に発生した欠陥。

2.ゲートチェックインビルド：このタイプのビルドでは、チェックインが行われた直後にビルドのチェックが開始され、シェルフセットの変更が維持されます。この場合、シェルフセットチェックインがコミットされるよりもビルドが成功すると、Team Foundation Serverにコミットされません。成功したチェックインのみがコミットを許可されるため、これは継続的インテグレーションビルドから少し良い画像を提供します。

3.ナイトリービルド：これは、スケジュールビルドとも呼ばれます。この場合、変更をビルドするために、ビルドを特定の時間実行するようにスケジュールします。最後のビルドからのコミットされていない以前のすべての変更は、このビルドプロセス中にビルドされます。これは、複数回チェックインしたいが、コードをチェックインするたびにビルドしたくない場合に実行されます。これにより、チェックインされたコードをビルドするためのビルドを開始できる一定の時間または期間を確保できます。

これらのビルドの詳細は、以下の場所にあります。

ビルドのゲートチェック

継続的インテグレーションビルド

ナイトリービルド

あなたはそれらを使ってきました-IDEはビルドツールです。コマンドラインでは、次のようなものを使用できますmake。

人々は毎晩のビルドなどにコマンドラインツールを使用しているため、二日酔いの朝、プログラマーはライブラリの最新のビルドをいじっていたコードが機能しないことに気づきました。

「...何を構築する必要があるかを追跡するのは非常に難しい」-構築ツールはそれだけでは役に立ちません。何を構築したいかを知る必要があります。（Ritesh Gunの答えから引用）

「ほとんどすべての種類の実際の開発で使用されていると聞きました」-何らかの理由で、ソフトウェア開発者は大企業で働きたいと思っています。彼らはそこで働くすべての個人に対してより不明確な作業指示を持っているようです。

「どうして私は過去4年間にそれらを必要としなかったのですか」。おそらくあなたは熟練したプログラマーだからです。

疑似メタ。ビルドツールは本当に本当のメリットを提供しないと思います。悪い会社の慣行、方向性の欠如、つまりプロジェクトの実際の悪い知識につながる悪いソフトウェアアーキテクチャのリーダーシップから生じる安心感を追加するためにそこにあります。プロジェクトでビルドツール（テスト用）を使用する必要はありません。ソフトウェアプロジェクトの知識が不足している状態でランダムなテストを行うことは、何の助けにもなりません。

プロジェクトの目的と、それが他のコンポーネントとどのように連携するかを知らずに、プロジェクトに何かを追加してはなりません。コンポーネントは個別に機能することができますが、一緒に機能することはできません。（これは私が想定するソフトウェアアーキテクトの責任です）。

4〜5個のコンポーネントがプロジェクトに追加された場合はどうなりますか。6番目のコンポーネントを追加します。最初に追加されたコンポーネントとともに、すべてを台無しにする可能性があります。自動はそれを検出するのに役立ちません。

考えると思う以外に近道はありません。

次に、リポジトリからの自動ダウンロードがあります。どうしてそんなことしたいの？何をダウンロードし、何をプロジェクトに追加するかを知る必要があります。リポジトリのバージョンの変更をどのように検出しますか？あなたが知る必要があります。何も「自動」にすることはできません。

自転車で目隠しをして自転車で移動したり、ベビートランスポートを棒でランダムにぶつけたりしてみたらどうでしょう。それは、ビルドツールのテストのアイデアのようです。

申し訳ありませんが 、https：//en.wikipedia.org/wiki/Scientific_methodおよび https://en.wikipedia.org/wiki/Analysisのショートカットはありません