JavaEE : Need better deployment system

Question

我们目前正在使用 JDeveloper 来构建我们的生产 EAR。这样做的一个问题是，如果开发人员不向 VCS 添加新文件，那么该开发人员是唯一能够制作 EARS 的人，因此他也可以使用未版本化的文件。

什么是一个好的系统来将其分开，以便可以正确生成 EAR 文件而不依赖于本地开发人员工作区(这也将确保他们在允许进行部署/检查之前将其文件添加到 VCS)中)。

Answer 1

One problem with this is that if the developer doesn't add new files to a VCS, then that developer is the only one capable of making EARS,

如果开发人员不使用 VCS，这不是您唯一的问题:

• 您无法在另一个环境中重现事物，您被绑定(bind)到开发人员计算机(但您知道这一点)。如果他生病了怎么办？
• 不对文件进行版本控制意味着您没有任何修改历史记录，并且您不知道将哪些内容投入生产(“嗯，这个版本中有什么？等等，让我们打开 EAR 来检查一下。”) .
• 最后但并非最不重要的一点是，如果发生硬件故障(例如硬盘驱动器崩溃)，您可以告别 VCS 中未包含的所有内容。

因此，要解决的第一问题是始终版本文件，即使只有一个开发人员，因为单独工作并不能避免您遇到上述问题。这些要点需要提醒(开发者需要意识到它们以了解它们的重要性)。

为了确保这种情况发生，您实际上不应该依赖开发人员机器来构建 EAR，而应该依赖作为引用的“外部”进程。您想避免这种综合症:

alt text http://img716.imageshack.us/img716/9901/worksonmymachinestarbur.png

要实现这样的流程，您需要自动化构建(即整个构建可以在一个命令中运行)并打破与 IDE 的依赖关系。换句话说，不要使用 IDE 来构建 EAR，而是使用类似 Maven 的工具。或Ant (与 IDE 无关)。这将是第二要解决的问题。

一旦您实现了构建过程的自动化，您就可以更进一步并连续运行它:这称为 Continuous Integration (CI) 并允许获得关于变更的频繁、最好是即时的反馈(以避免大爆炸集成问题)。这将是要解决的第三问题。

鉴于您的实际工具集(远非理想，您正在使用的工具没有太多社区支持)，我的建议是使用 Ant(或 Maven，如果您对此有一定的了解)进行构建和Hudson用于持续集成(因为它非常容易安装和使用，并且它有一个 Dimensions plugin )。