私の長年のJavaプログラミング、最近ではScalaで、Ant、Maven、Gradle、またはJava用のビルドツールを使用したことがありません。私が働いていたすべての場所に、そのすべてを処理するビルドマネージャーがいました-開発と単体テストのためにIDEでローカルにコンパイルし、ソースコードをチェックインし、必要なことをしたビルドマネージャーに通知しました共有環境用に全員のファイルをコンパイルします。

契約の合間に、私は自分で資金を提供するプロジェクトに取り組んでおり、実際にお金を稼ぐのに十分なレベルに達しつつあります。私も潜在的な投資家を揃えており、今後数週間以内にベータ版を見せることを計画しています。

しかし、ずっとIDEのビルドボタンをクリックするだけで、Jarファイルが作成され、正常に機能します。もちろん、従来の知識では、私は自分でAnt / Maven / Gradleスクリプトを作成し、IDEの代わりにそれを使用する必要があると示唆していますが、私の状況での具体的な利点は何ですか（単独で作業）？

私はこれらのビルドツールの使用方法について読んでいますが、IDEがワンクリックで行うこと（IDEで生成されたものプロジェクトのAnt XMLは700行を超えています）。エラーが発生しやすく、時間がかかり、私の状況では不必要に見えます。学習曲線は言うまでもありません。学習曲線は、他のすべての作業から時間を奪って、製品を人々に見せるために準備します。

AntではなくMavenの使用を検討することをお勧めします。IDEがワンクリックでプロジェクトをビルドできる場合、Mavenはカスタム構成を実質的に使用せずにプロジェクトをビルドできる可能性があります。

そして、質問に答えるために、展開プロセスを単純化することが具体例の1つ​​です。配布可能ファイルをローカルで構築している場合、その配布可能ファイルを運用システムに手動で展開する必要があり、展開の準備を整えるために運用システムでかなりの手動設定を行う必要があることを意味します（Tomcatのインストール、おそらく、またはアプリケーションに必要な依存関係とリソースをコピーします）。これには時間がかかり、更新プログラムの展開が面倒な手動プロセスになる場合があります。また、実稼働プラットフォームと開発環境との間にわずかな構成の違いがあり、曖昧で追跡が困難なエラーを引き起こす可能性があります。

とにかく、この手作業の退屈な仕事を取り除くために私がすることは、Mavenでビルドするようにプロジェクトを構成し、pom.xml（Java Webアプリの場合）を見つけてダウンロードするために必要なすべての情報でファイルを構成することですTomcatの正しいバージョンをローカルにインストールし、正しいTomcat構成ファイルをセットアップし、プロジェクトの依存関係とプロジェクトWARファイル自体をデプロイしてから、Tomcatを起動します。次に、.batMavenを使用してサーバーを構築および起動する単純なシェルスクリプト（およびWindows用のバージョン）を作成します。

mvn clean install cargo:start -Dcargo.maven.wait=true

したがって、開発環境にデプロイ可能ファイルをパッケージ化し、それを本番環境に手動でプッシュするのではなく、私がしなければならないのは、バージョン管理システムから本番サーバーに同期するだけです。その後、本番システム自体がビルド、インストール、実行デプロイ可能（および、開発システムで実行される方法と同じ方法で実行され、プラットフォーム固有のエラーや設定ミスの可能性を最小限に抑えます）。そして、開発環境でも運用環境でも、サーバーを構築して起動するために私がすることは次のとおりです。

./startServer.sh #or startServer.bat for Windows

そして、実稼働環境に更新プログラムを展開するためのプロセスは次のとおりです。

1. 実行中のサーバーインスタンスがあれば停止します。
2. を実行しますsvn update -r<target_release_revision>。
3. を実行します./startServer.sh。

シンプルで覚えやすいし、IDEを使用してデプロイ可能ファイルを構築することに頼っていた場合は、まったく実行できません。また、ロールバックが必要になった場合に、最後の既知の適切な展開に戻すのも簡単です。

展開と構成のプロセスを手動で管理しようとすることで、このアプローチが私を救った時間を数えることさえできません。

そしてもちろん、あなたの質問に対する別の答えは自動依存関係管理ですが、それはすでに他の答えでカバーされていると思います。

コードがソース管理内にある限り、IDEを使用して配布可能ファイルを作成しても問題ありません。

ワンマンショップとして、製品に新機能を追加したり、ビルドスクリプトを記述したりするのに時間を費やした方がいいですか ビルドスクリプトを記述していないことがわかります。

確かに、あなたが一人で働いているときの利点を見るのは難しいです。個人的に、私はたくさんのソロプロジェクトに携わっており、ビルドスクリプトを書くだけでなく、CI Server（Jenkinsなど）をセットアップするのに苦労しています。

もちろんオーバーヘッドがありますが、なぜそれだけの価値があるのでしょうか？

• IDE（または外部で実行する場合はマシン）に関連付けられていない、再現可能なビルド。ビルドサーバーで実行すると、他のマシンで実行できます。
• 楽しさは、建物やユニットテストの後に開始されます（ちなみに：あなたは確か？ごとにコミットする前にあなたは私が時々忘れテスト）。ドキュメントの生成、インストーラーの構築、お気に入りのコード分析ツールの実行。
• お気に入りのCIサーバーを使用すると、コードカバレッジ、単体テストの失敗などのグラフを経時的に表示できます。あなたのIDEはそれをしますか？

私の現在のプロジェクトでは、スクリプトは静的分析ツールを構築、実行し、js / css、ユニットテスト、およびパッケージをWebアーカイブに圧縮します。Jenkinsは各コミット後にそれを実行し、プロジェクトをテストサーバーにデプロイします。

私はこれをセットアップするために時間をかけました（ビルドスクリプトは多分 300行で、数か月後には触れていません）。1人でも価値があると言えます。複数の人にとって、それは必要です。ビルド/展開プロセスへの私の関与は、コマンド「hg commit」および「hg push」で構成されています。

ビルドツールの利点

これは氷山の一角を示す短い要約であり、多くのプロジェクト、大規模プロジェクト、中規模から大規模なチームの組み合わせを行う必要がない限り、このすべての重要性に必ずしも気付くことはありません。しかし、あなたが信仰を持ってやってみれば、その恩恵を受けるでしょう。

開発ライフサイクルを促進し、次のことを可能にします。

• プロジェクトを一貫して簡単に整理および構成する
• プロジェクト全体でグッドプラクティスを再利用し、それらを簡単かつ迅速に開始します。
• 単一のビルドに複数のプロジェクトを統合し、
• 自動化あなたの継続的インテグレーションプロセスを、
• プロジェクトを他の人と共有する
  • 特定のツールキットまたはIDE（ビルドシステムを除く）を使用するように強制することなく、
  • そして、彼らは標準的なビルドを期待するので、それらを驚くことなく
• 製品のメンテナンスを自動化および促進する
• 製品のリリースプロセスを自動化する

これをMavenに適用すると...

Javaの世界でMavenを使用しているユーザーの場合、これを読むことで、各ポイントを自然に次のように関連付けることができます。

• Mavenの構造化プロジェクトコンベンション
• Mavenアーキタイプ
• SCMおよびリアクタービルドからプロジェクトを具体化する
• Jenkins / Hudson / Bamboo /その他のサポート+統合テストプラクティスに対するMavenのサポート
• m2eclipse、ネイティブIntelliJまたはNetBeansサポート-またはコマンドラインのmvnsh
• versions-maven-plugin
• maven-release-plugin、buildnumber-maven-pluginプラグイン、versions-maven-plugin

そしてもちろん、Maven（他のツールも同様）は依存関係管理を提供します。これは（チームの人数に応じて）あなたのSCMにとって大きな時間とスペースの節約になります。

すべてが相対的：

Mavenを例として使用しているのは、Mavenが最も包括的で「バッテリーを含む」ビルドシステムだと思うからですが、必ずしも「最高」だというわけではありません。ただし、上記のすべてのチェックボックスに適合します。適切なビルドシステムを探す場合は、このリストおよびMavenと比較します。ただし、標準化されたプロセスから逸脱する場合、Mavenは常に非常に柔軟であるとは限りません-ただし、非常に拡張性があります。それはあなたがそれを戦う場合ではなく、一般的な場合（学習曲線よりも先に）にあなたの生産性を高めます。

ビルドツールを使用する私の上位4つの理由を次に示します。

• 依存関係の処理（エラーの回避）
• テスト（変更は他のモジュールを破壊しませんでした-テストがはるかに簡単です）
• 安全なコミット
• ローカル配布可能ファイルを簡単にデプロイできます（QA envで、ビルダーがプロジェクトとその依存関係をビルドするのを待つ時間はありません）

Pragmatic Programmerの本で、Andrew HuntとDavid Thomasは、「checkout-build-test-deploy」は単一のコマンドであるべきだと言っています（Chapter：Pragmatic Projects）。あなたが書いた..

私も潜在的な投資家を揃えており、今後数週間以内にベータ版を表示する予定です

それから、あなたのチームが成長することを確信しています。

見た大きなXML（スクリプト）は、通常1回限りの仕事です。ほとんどの場合、同じスクリプトを多くのプロジェクトで使用できます。

プロジェクトの規模は明確ではありません。統合されたテスト/受け入れテストに大量のCPU /メモリが必要な場合は、テストサーバーとして別のマシンを使用することを検討してください。また、ソースコード/バイトコードを分析するツールのホストを展開することもできます。

一人の開発者にとって、スクリプトビルドのような優れたプロセスと構造を持つことは、チームにいるときよりも非常に重要であると私は主張します。あなたがコーナーをカットするときにあなたを呼び出すチームメイトを持っていないという理由。ビルドスクリプトを実行するCIサーバーは、妥協のない優れたチームメイトになり、正直になります。

コードベースが大きくなると、テストスイートを追加する必要があります。私の経験では、これは後で行うよりも早く行う必要があり、毎晩（または何でも）ビルドで毎回すべてのテストを実行する必要があります。最初は小さく、自動生成されたXMLはおそらく問題ありません。他の何かを壊すことを恐れて何かを変えるのが怖いとき、それはいくつかのテストケースを書き上げる良い動機です。

IDE以外のビルドを使用すると、IDEを当時のように再構成することを心配することなく、古いバージョンを簡単に再構築できます。テストを実行することを忘れずにテストを中断し、完了するのを待つ場合。

また、サーバーへのsshなど、GUI以外の環境でビルドを実行でき、ソフトウェアをビルドする機能を失うことを心配せずにIDEを切り替えることができます。

一部のビルドツールは、タグ付けとリリースの自動化を支援したり、コードカバレッジレポートを生成するための適切なデフォルトを備えています。

さらに人を追加すると、ビルドツールは、他の誰かの貧弱なIDE構成に対して脆弱でないことを確認します。同僚がビルドツールを使用していないため、同僚のEclipseインストールを修正するために、定期的にスクリーン共有を行っています（作業中）。

最終的な理由は、手動で行う必要がないため、手動で行わないことです。それ以外はすべてそこから抜け落ちます。