部署 J2EE/Java Web 应用程序的两种主要方法(在非常简单的意义上):
将组装的工件部署到生产盒
在这里,我们在.war
别处创建(或其他),将其配置用于生产(可能为许多盒子创建大量工件)并将生成的工件放在生产服务器上。
- 优点:生产盒上没有开发工具,可以直接重用测试中的工件,进行部署的人员不需要了解构建过程
- 缺点:创建和部署工件的两个过程;预建工件的潜在复杂配置可能会使流程难以编写脚本/自动化;必须版本二进制工件
在生产箱上构建工件
在这里,日常用于在开发人员机器上本地构建和部署的相同过程用于部署到生产。
- 优点:需要维护一个流程;并通过频繁使用进行了大量测试/验证。在创建工件时自定义配置可能比自定义预构建工件后记更容易;不需要对二进制工件进行版本控制。
- 缺点:所有生产盒都需要潜在的复杂开发工具;部署人员需要了解构建过程;你没有部署你测试的东西
我主要使用第二个过程,诚然是出于必要(另一个部署过程没有时间/优先级)。就我个人而言,我不赞成“生产箱必须清除所有编译器等”之类的论点,但我可以看到部署您测试过的东西的逻辑(而不是构建另一个工件)。
然而,Java Enterprise 应用程序对配置非常敏感,感觉就像是在为配置工件的两个进程自找麻烦。
想法?
更新
这是一个具体的例子:
我们使用 OSCache,并启用磁盘缓存。配置文件必须在 .war 文件中,并且它引用文件路径。这条路径在每个环境中都不同。构建过程检测用户的配置位置,并确保放置在战争中的属性文件对于他的环境是正确的。
如果我们要使用构建过程进行部署,则需要为生产环境(例如production.build.properties
)创建正确的配置。
如果我们要遵循“将组装的工件部署到生产环境”,我们将需要一个额外的过程来提取(不正确的)OSCache 属性并将其替换为适合生产环境的属性。
这会创建两个进程来完成同一件事。
所以,问题是:
- 如果没有“在生产中编译”,这是否可以避免?
- 如果没有,这值得吗?“不编译生产”的价值是否大于“不要重复自己”?