在Java和Scala编程的多年中，我从未使用过Ant，Maven，Gradle或任何这些Java构建工具。在我工作过的所有地方，都有一个构建经理来负责所有这些工作-我将使用IDE在本地进行编译以进行开发和单元测试，然后检查源代码，并通知构建经理完成了必要的工作。为共享环境编译每个人的文件。

现在，我处于合同之间，我一直在从事我自己的自筹资金项目，现在正好可以实际赚钱。我什至有潜在的投资者在排队，并计划在未来几周内向他们展示Beta版本。

但是一直以来，我只是单击IDE上的build按钮，它会创建Jar文件，并且效果很好。当然，传统的观点建议我“应该”编写自己的Ant / Maven / Gradle脚本并使用它而不是IDE，但是在我的情况下（单独工作）它的具体优势是什么？

我已经阅读了一些有关如何使用这些构建工具的文章，看起来我将编写数百行XML（或Groovy或其他内容）以一键完成IDE的工作（IDE生成的该项目的Ant XML超过700行）。它看起来容易出错并且很耗时，对于我的情况来说是不必要的。更不用说学习曲线了，这将使我为使产品准备向人们展示而正在做的所有其他工作都浪费了时间。

我建议您考虑使用Maven而不是Ant。如果您的IDE可以一键构建项目，那么Maven几乎也可以在没有自定义配置的情况下构建您的项目。

为了回答这个问题，简化部署过程就是一个具体的例子。如果要在本地构建可分发文件，则意味着您必须在生产系统上手动部署该可分发文件，这意味着您可能必须在生产系统上进行相当多的手动配置才能使其准备好进行部署（安装Tomcat） ，或者复制应用程序所需的依赖项和资源）。这可能很耗时，并且可能使部署更新成为繁琐的手动过程。它还使您的生产平台和开发环境之间的任何微小配置差异都有可能导致模糊，难以跟踪的错误。

因此，无论如何，要摆脱这种繁琐的工作，我需要配置要使用Maven构建的项目，并pom.xml使用（对于Java Web应用程序）查找并下载所需的所有信息来配置文件。正确的Tomcat版本，在本地安装，设置正确的Tomcat配置文件，部署任何项目依赖项和项目WAR文件本身，然后启动Tomcat。然后，我创建一个简单的shell脚本（以及.batWindows的一个版本），该脚本使用Maven来构建和启动服务器：

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服务器（如Jenkins）的麻烦。

当然会有开销，为什么值得呢？

• 可复制的内部版本，与IDE（或计算机，如果在外部运行）无关。如果构建服务器运行它，则其他机器也可以运行它。
• 有趣的是在构建和单元测试之后开始（顺便说一句：您确定在每次提交之前都进行测试吗？我有时会忘记）。生成文档，构建安装程序，运行您喜欢的代码分析工具。
• 您最喜欢的CI服务器使您可以查看代码覆盖率，单元测试失败等随时间变化的图表。您的IDE可以做到吗？

对于我当前的项目，该脚本将构建，运行静态分析工具，压缩js / css，单元测试并将程序包打包到Web存档中。Jenkins在每次提交后运行它，并将项目部署到测试服务器。

我花了一些时间进行设置（顺便说一句，构建脚本可能是300行，几个月没有接触过它），并且可以说值得，即使对于一个人也是如此。对于一个以上的人，这是必要的。我参与构建/部署过程的过程包括命令“ hg commit”和“ hg push”。

构建工具的好处

这是一个简短的摘要，仅显示了冰山一角，除非您需要将许多项目，大型项目和中型到大型团队结合在一起使用，否则您不一定会注意到所有这一切的重要性。但是，如果您有信心并尝试，您将获得好处。

它们有助于您的开发生命周期，并且使您能够：

• 一致，轻松地组织和组织项目
• 在各个项目中重复使用良好做法，并轻松，快速地启动它们，
• 在一个版本中集成多个项目
• 自动执行您的持续集成过程，
• 与他人分享您的项目
  • 无需强制他们使用特定的工具箱或IDE（构建系统除外），
  • 并且毫不奇怪，因为他们期望标准的构建
• 自动化和方便的维修您的产品
• 自动化产品的发布过程

如果我们将其应用于Maven ...

对于Java世界中使用Maven的那些人，通过阅读此书，您很自然地将每个点与：

• Maven的结构化项目约定
• Maven原型
• 从SCM和反应堆构建中实现项目
• Jenkins / Hudson / Bamboo /其他支持+ Maven对集成测试实践的支持
• m2eclipse，本机IntelliJ或NetBeans支持-或mvnsh用于命令行
• 版本Maven插件
• maven-release-plugin，buildnumber-maven-plugin插件和版本-maven-plugin

当然，Maven（还有其他工具）还为您提供了依赖项管理，这对于您（取决于团队中的人员数量）和您的SCM 是一个节省大量时间和空间的工具。

一切都是相对的：

我以Maven为例，因为我认为它是最全面且“包含电池”的构建系统，但这并不意味着它一定是“最佳”的。它确实适合上面列出的所有复选框，并且在寻找一个好的构建系统时，我将其与该列表和Maven进行了比较。但是，如果您偏离标准流程，则Maven并不总是很灵活-但是它却非常可扩展。在一般情况下（一旦超过学习曲线），它可以提高您的生产力，而不是与您抗争。

这是我使用构建工具的4大理由：

• 依赖项处理（避免错误）
• 测试（您的更改没有破坏其他模块-测试起来容易得多）
• 安全提交
• 易于部署本地可分发项（没有人在QA环境中等待构建器构建您的项目及其依赖项）

在《实用程序员》一书中，安德鲁·亨特和戴维·托马斯说，“ checkout-build-test-deploy”应该是一个命令。你写了..

我什至有潜在的投资者在排队，并计划在接下来的几周内向他们展示测试版

然后，我相信您的团队将不断壮大。完成自动测试部署功能显得尤为重要。

您看到的大型XML（脚本）通常是一次性的工作。在大多数情况下，可以在许多项目中使用相同的脚本。

目前尚不清楚该项目有多大。如果您的集成测试/验收测试占用大量CPU /内存，则可以考虑使用另一台计算机作为测试服务器。您还可以部署大量工具来分析源代码/字节码。

我认为，对于一个孤独的开发人员而言，拥有良好的流程和结构（如脚本生成）比在团队中时要重要得多。原因是当您偷工减料时，您没有队友呼唤您。运行您的构建脚本的CI服务器可以使您成为一个毫不妥协的队友，以使您保持诚实。

随着代码库的增长，您将需要添加测试套件。我的经验是，应该早点而不是晚一点，并且您的每晚（或任何版本）构建应该每次都运行所有测试。从小处着手，自动生成的XML可能很好。当您因害怕破坏其他东西而害怕更改某些东西时，这是编写一些测试用例的良好动力。

非IDE构建使您可以轻松地重建旧版本，而不必担心按当时的方式重新配置IDE，使您可以非交互方式执行构建，从而可以维持夜间构建以供人们测试或快速查找。如果您在不记得要运行它们并等待它们完成的情况下中断了测试。

它还使您可以在非GUI环境中执行构建，例如，将其SSH到服务器，并允许您切换IDE，而不必担心失去构建软件的能力。

一些构建工具可帮助您自动标记和部署发行版，并带有适当的默认值以生成代码覆盖率报告等。

当您添加更多人员时，构建工具将确保您不会受到别人不良的IDE配置的攻击。我经常进行屏幕共享以修复同事的Eclipse安装，因为他们不使用构建工具（在该工具上工作）。

不过，最终的原因是它不需要手动完成，所以不要手动进行。其他一切都从那开始。