java 什么是构建自动化软件（例如 Ant）？

What is build automation software (for example, Ant)?

提问by Click Upvote

I see reference of ant a lot but I don't get exactly what its meant to do? from what i've heard its supposed to compile your projects but can't i just do that by clicking Run->Run in eclipse?

我经常看到 ant 的参考资料，但我不明白它到底是什么意思？据我所知，它应该编译您的项目，但我不能通过在 eclipse 中单击 Run->Run 来做到这一点吗？

Edit : I guess I should rephrase my question. I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?

编辑：我想我应该改写我的问题。我已经知道 ant 是一个“构建自动化软件”，我的问题是，构建自动化到底是什么？我认为你应该测试你的应用程序，当它运行时你在 eclipse 中或通过命令行 java 单击“构建”按钮，它会从中生成一个 .jar 文件？那么为什么需要“自动化”这个过程呢？

回答by OscarRyz

I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?

我已经知道 ant 是一个“构建自动化软件”，我的问题是，构建自动化到底是什么？我认为你应该测试你的应用程序，当它运行时你在 eclipse 中或通过命令行 java 单击“构建”按钮，它会从中生成一个 .jar 文件？那么为什么需要“自动化”这个过程呢？

Not all the Java development is done through eclipse and not all the jars may be built from the command line ( or should be built from the command line ) .

并不是所有的 Java 开发都是通过 eclipse 完成的，也不是所有的 jars 都可以从命令行构建（或者应该从命令行构建）。

You may need additionally run test cases, unit tests, and many, many other process.

您可能需要额外运行测试用例、单元测试和许多其他过程。

What ant does, is provide a mechanism to automate all this work ( so you don't have to do it every time ) and perhaps you may invoke this ant script each day at 6 p.m.

ant 所做的是提供一种机制来自动执行所有这些工作（因此您不必每次都这样做），也许您可​​以在每天下午 6 点调用此 ant 脚本

For instance, in some projects, a daily build is needed, the following are the task that may be automated with ant, so they can run without human intervention.

比如在一些项目中，需要每天进行一次构建，下面的任务可能会被ant自动化，这样它们就可以在没有人为干预的情况下运行。

• Connect to subversion server.
• Download/update with the latest version
• Compile the application
• Run the test cases
• Pack the application ( in jar, war, ear, or whatever )
• Commit this build binaries to subversion.
• Install the application in a remote server
• Restart the server
• Send an email with the summary of the job.

• 连接到颠覆服务器。
• 下载/更新最新版本
• 编译应用程序
• 运行测试用例
• 打包应用程序（在 jar、war、ear 或其他任何地方）
• 将此构建二进制文件提交给颠覆。
• 在远程服务器上安装应用程序
• 重启服务器
• 发送包含工作摘要的电子邮件。

Of course for other projects this is overkill, but for some others is very helpful.

当然，对于其他项目，这有点矫枉过正，但对于其他一些项目则非常有帮助。

回答by Jon Skeet

rogeriopvlis absolutely correct, but to answer your "can't I just do that by clicking Run->Run in Eclipse?" question: that's fine for a project that you're working on on your own, and don't need a repeatable, scriptable build in multiple environments.

rogeriopvl是绝对正确的，但是要回答您的“我不能通过单击 Run->Run in Eclipse 来做到这一点吗？” 问题：这对于您自己进行的项目来说很好，并且不需要在多个环境中进行可重复的、可编写脚本的构建。

If you're working on an open source project, however, or professional software which needs to be able to build on a build server etc, requiring a particular IDE to be running isn't a good idea.

但是，如果您正在开发一个开源项目，或者需要能够在构建服务器等上构建的专业软件，那么需要运行特定的 IDE 并不是一个好主意。

回答by mtruesdell

Ant is used to automate a build process, but a build process is often much more than compiling. Ant has "tasks" that can be used to perform miscellaneous useful functions. You can create your own task to do just about anything by writing a java class and telling ant where to find it. You can then mix and match these tasks to create targets that will execute a set of tasks.

Ant 用于自动化构建过程，但构建过程通常不仅仅是编译。Ant 具有可用于执行各种有用功能的“任务”。您可以通过编写一个 java 类并告诉 ant 在哪里找到它来创建自己的任务来做任何事情。然后，您可以混合和匹配这些任务以创建将执行一组任务的目标。

You can also set up a dynamic environment in which to build your application. You can set up property files to hold variables that can be used in the build process, i.e. to hold file paths, class paths, etc. This is useful for instance to differentiate between test and production builds where deployment paths, database instances, etc. might change. Ant also includes flow control (if, etc.)

您还可以设置一个动态环境来构建您的应用程序。您可以设置属性文件来保存可在构建过程中使用的变量，即保存文件路径、类路径等。这对于区分测试构建和生产构建非常有用，例如部署路径、数据库实例等。可能会改变。Ant 还包括流量控制（if 等）

Some things I've seen ant do:

我见过蚂蚁做的一些事情：

• Compile code
• Use version control to checkout the latest version or to tag the version being built
• Run sql scripts to build or rebuild a test database
• Copy files from an external resource for inclusion in a project
• Bundle code into a jar, war or ear file
• Deploy a web application to an application server
• Restart an application server
• Execute a test suite
• Static analysis, i.e. CheckStyleor PMD
• Send email to a team to alert them to a build.
• Generate files based on information from the build.
  • Example: I have a jsp in my app that does nothing but display version/build information. It is generated by ant when I run a build, and the production operations team checks this page when they deploy the application to make sure they've deployed the correct build.

• 编译代码
• 使用版本控制检查最新版本或标记正在构建的版本
• 运行 sql 脚本来构建或重建测试数据库
• 从外部资源复制文件以包含在项目中
• 将代码打包成 jar、war 或 ear 文件
• 将 Web 应用程序部署到应用程序服务器
• 重启应用服务器
• 执行测试套件
• 静态分析，即CheckStyle或PMD
• 向团队发送电子邮件以提醒他们注意构建。
• 根据构建中的信息生成文件。
  • 示例：我的应用程序中有一个 jsp，它只显示版本/构建信息。它是在我运行构建时由 ant 生成的，生产运营团队在部署应用程序时会检查此页面，以确保他们部署了正确的构建。

回答by oxbow_lakes

In many larger companies (and likely some smaller ones), you'll find that production code is not built by the people who developed it. Instead, the developers may check their code into a source code repository and tag it. Then they give this tag to a build team.

在许多较大的公司（可能还有一些较小的公司）中，您会发现生产代码不是由开发人员构建的。相反，开发人员可以将他们的代码检入源代码存储库并标记它。然后他们将此标签提供给构建团队。

The build team, in a separate (clean) area - possibly on some headless server (i.e. with no GUI) - will then check out the code and run a build script. The build script will be completely independent of the desktop environment/IDE.

构建团队在一个单独的（干净的）区域——可能在一些无头服务器（即没有 GUI）上——然后将检查代码并运行构建脚本。构建脚本将完全独立于桌面环境/IDE。

This ensures that nothing which happens to be on any one developer's computer is "polluting" the build. (Or, more likely, nothing outside source control is required for the system to work!)

这确保了任何一个开发人员的计算机上的任何东西都不会“污染”构建。（或者，更有可能的是，系统工作不需要任何外部源代码控制！）

So most software you use will never, everbe built from a developer's desktop.

因此，您使用的大多数软件永远不会是从开发人员的桌面构建的。

PS. You might also want to look at the idea of Continuous Integration

附注。您可能还想了解持续集成的想法

回答by Gary

The short answer is that Ant is a great way to create a complete project build that is independent of any particular tool any developer may be using. Without an independent build, things can go haywire quickly - especially for large project teams.

简短的回答是 Ant 是创建完整项目构建的好方法，该构建独立于任何开发人员可能使用的任何特定工具。如果没有独立的构建，事情会很快变得混乱 - 特别是对于大型项目团队。

And now for the long answer... I have been brought into several projects without any sense of an independent build. On one project, there was one guy who was not a developer that was tasked with building and deploying the software. He had created 147 separate windows batch files to compile each EJB, each servlet, and each client component. There was no error checking for this build. All log messages, including error messages went to standard out. It was up to him to manually recognize by reading this log which exception or message printed was a normal and which message was an error. He also had to deploy this software he just built. Deploying was equally as complex since there were several load-balanced tiers. Each module had to be placed in the right place manually with options setup to match downstream and upstream tiers. Building and deploying this software took him at least 3 days using this method. Of course, only then could anyone determine if the build "worked". Usually, after this period all the programmers would scramble to debug the build. Programmers would say my module works fine in my IDE. I just click run like this, see?

现在，对于长篇大论的回答......我被带入了几个项目，但没有任何独立构建的感觉。在一个项目中，有一个不是开发人员的人负责构建和部署软件。他创建了 147 个单独的 Windows 批处理文件来编译每个 EJB、每个 servlet 和每个客户端组件。此构建没有错误检查。所有日志消息（包括错误消息）都已标准化。他可以通过阅读此日志手动识别打印的哪些异常或消息是正常的，哪些消息是错误的。他还必须部署他刚刚构建的这个软件。部署同样复杂，因为有多个负载平衡层。每个模块都必须手动放置在正确的位置，并设置选项以匹配下游和上游层。使用这种方法构建和部署这个软件至少花了他 3 天的时间。当然，只有这样才能确定构建是否“有效”。通常，在这段时间之后，所有程序员都会争先恐后地调试构建。程序员会说我的模块在我的 IDE 中运行良好。我就这样点击运行，看到了吗？

Indeed, the individual software modules usually worked, but the build and deployment was horribly ineffective. And just as bad, it was equally as difficult for anyone to deploy a build to more than one environment. Management would say, ok you now have this build working in our regression testing environment. Now deploy that same build in this other environment so the sales guys can demo up and coming software. That should be simple to do, but it also took at least 2 days, followed by a "debugging the build" period. Builds and deploys were never simple and never accurate. It really slowed the project down.

事实上，单个软件模块通常可以工作，但构建和部署却非常低效。同样糟糕的是，任何人将构建部署到多个环境也同样困难。管理层会说，好的，您现在可以在我们的回归测试环境中使用此构建。现在在另一个环境中部署相同的构建，以便销售人员可以演示即将推出的软件。这应该很容易做到，但也至少需要 2 天，然后是“调试构建”期。构建和部署从来都不是简单的，也不是准确的。这确实拖慢了项目的进度。

Anyway, we replaced this entire procedure with a complete Ant based build and deploy mechanism. The end result was that a complete build could be created and deployed in less than 30 minutes, completely automated. The QA guy managing the builds and deploys could keep a whiteboard of which environment had which build deployed to it and which group was using that environment. This was something that was just not possible with the old system.

无论如何，我们用完整的基于 Ant 的构建和部署机制替换了整个过程。最终结果是可以在不到 30 分钟的时间内创建和部署完整的构建，完全自动化。管理构建和部署的 QA 人员可以保留一个白板，说明哪个环境部署了哪个构建以及哪个组正在使用该环境。这是旧系统无法实现的。

回答by rogeriopvl

Ant is for automating software build processes:

Ant 用于自动化软件构建过程：

http://en.wikipedia.org/wiki/Apache_Ant

http://en.wikipedia.org/wiki/Apache_Ant

回答by Fabian Steeg

Ant allows CRISP (complete, repeatable, informative, schedulable, portable) builds. You can find great info on it in this presentationby Mike Clark and in his book, Pragmatic Project Automation.

Ant 允许 CRISP（完整的、可重复的、信息丰富的、可调度的、可移植的）构建。您可以在Mike Clark 的这个演讲和他的书Pragmatic Project Automation 中找到有关它的重要信息。

回答by Joey

Ant is a build tool, akin to makefiles (albeit with a very different syntax in XML). If you're only using Eclipse it's fine to stick to that and you can always convert an Ant build file into an Eclipse project (Eclipse's launch configurations are then, if I remember correctly, the equivalent of Ant's build targets).

Ant 是一种构建工具，类似于 makefile（尽管在 XML 中有非常不同的语法）。如果您只使用 Eclipse，那么坚持这一点很好，并且您始终可以将 Ant 构建文件转换为 Eclipse 项目（如果我没记错的话，Eclipse 的启动配置就相当于 Ant 的构建目标）。

If you want to deploy the source code of the application and allow others to easily build or set it up, automating that using Ant is probably not a bad idea. But it's usually not a consistent experience for users or at least I haven't seen much consensus on what targets should be there and doing what so far.

如果您想部署应用程序的源代码并允许其他人轻松构建或设置它，那么使用 Ant 自动化可能不是一个坏主意。但对于用户来说，这通常不是一致的体验，或者至少我还没有看到关于应该有哪些目标以及到目前为止做什么的共识。

Ant may also be used for regular automated builds (you wouldn't want to hit Run in Eclipse every night, right? :-))

Ant 也可用于常规的自动化构建（您不会希望每晚都在 Eclipse 中运行，对吗？:-)）

回答by Jeffrey Fredrick

If there's one close to you I think you'd get a lot out of CITCON, the Continuous Integration and Testing Conference. You get to talk with lots of people about the benefits of automation applied to building and testing software.

如果您身边有人，我想您会从CITCON（持续集成和测试会议）中获益良多。您可以与很多人讨论应用于构建和测试软件的自动化的好处。

Basically people use Ant (with other tools) to automate everything they want to have happen after a commit. The basic advantages of such automation are faster, better and cheaper.

基本上人们使用 Ant（和其他工具）来自动化他们希望在提交后发生的一切。这种自动化的基本优势是更快、更好和更便宜。

Fasterbecause things happen right away without waiting for a human to get around to it.

更快，因为事情会立即发生，而无需等待人来处理。

Betterbecause computers are really really good at doing the same thing the same way every time. (Humans tend to suck at that.)

更好，因为计算机真的很擅长每次都以同样的方式做同样的事情。（人类往往对此感到厌烦。）

Cheaperbecause you have fewer mistake and the mistakes that occur are caught sooner and therefore cheaper to fix.

更便宜，因为您的错误更少，并且发生的错误更早被发现，因此修复成本更低。

回答by Jared

Joel (Spolsky) has a great articleon "The Joel Test." Many of them revolve around being able to do important things often, quickly and reliably. One of those things is your build.

Joel (Spolsky) 有一篇关于“乔尔测试”的精彩文章。他们中的许多人都围绕能够经常、快速和可靠地做重要的事情。其中之一就是您的构建。