部署J2EE/Java Web应用程序的两种主要方式(以非常简单的方式):
在这里,我们在.war其他地方创建(或其他),将其配置为生产(可能为多个框创建大量工件)并将生成的工件放置在生产服务器上.
优点:生产箱上没有开发工具,可以直接重复使用工件,部署人员不需要构建过程的知识
缺点:创建和部署工件的两个过程; 预先构建的工件的潜在复杂配置可能使进程难以编写脚本/自动化; 必须版本二进制工件
在这里,用于在开发人员盒上本地构建和部署的相同过程用于部署到生产.
优点:维持一个过程; 并经常使用经过严格测试/验证.在工件创建时可能更容易定制配置,而不是定制预先构建的工件后缀; 不需要版本化二进制工件.
缺点:所有生产箱都需要潜在的复杂开发工具; 部署人员需要了解构建过程; 你没有部署你测试的东西
我主要使用第二个进程,不可否认(没有时间/优先级用于另一个部署过程).就个人而言,我不会购买诸如"生产盒必须清理所有编译器等"之类的论点,但我可以看到部署你测试过的逻辑(而不是构建另一个工件).
但是,Java Enterprise应用程序对配置非常敏感,感觉就像在配置工件的两个过程中遇到麻烦一样.
思考？
这是一个具体的例子:
我们使用OSCache,并启用磁盘缓存.配置文件必须位于.war文件中,并引用文件路径.每条环境都有不同的路径.构建过程检测用户配置的位置,并确保放置在战争中的属性文件对其环境是正确的.
如果我们要使用构建过程进行部署,那么就需要为生产环境创建正确的配置(例如production.build.properties).
如果我们遵循"将组装的工件部署到生产框",我们需要一个额外的过程来提取(不正确的)OSCache属性并将其替换为适合生产环境的属性.
这创建了两个完成相同事情的过程.
所以,问题是:
没有"编制生产"这是否可以避免？
如果没有,这值得吗？"没有编译生产"的价值大于"不要重复自己"吗？
David Leppik.. 7
我坚决反对在生产盒上构建,因为这意味着你使用的是与你测试过的不同的版本.它还意味着每个部署机器都有不同的JAR/WAR文件.如果不出意外,请进行统一构建,以便在进行错误跟踪时,您不必担心服务器之间的不一致.
此外,如果您可以轻松地在构建和创建它的源之间进行映射,则无需将构建版本置于版本控制中.
在我工作的地方,我们的部署过程如下.(这是在Linux上,与Tomcat一起使用.)
测试更改并检查Subversion.(不一定按照这个顺序;我们不要求提交代码进行测试.我是唯一的全职开发人员,因此SVN树本质上是我的开发分支.您的里程可能会有所不同.)
将JAR/WAR文件复制到以Subversion修订版号命名的共享目录中的生产服务器.Web服务器只具有读访问权限.
部署目录包含指向修订版目录中文件的相对符号链接.这样,目录列表将始终显示生成运行版本的源代码版本.部署时,我们更新的日志文件只是目录列表.这使得回滚变得容易.(但有一点问题; Tomcat会根据真实文件的修改日期检查新WAR文件,而不是符号链接,因此我们必须在回滚时触摸旧文件.)
我们的Web服务器将WAR文件解压缩到本地目录中.该方法是可扩展的,因为WAR文件位于单个文件服务器上; 我们可以拥有无限数量的Web服务器,只进行一次部署.
我坚决反对在生产盒上构建,因为这意味着你使用的是与你测试过的不同的版本.它还意味着每个部署机器都有不同的JAR/WAR文件.如果不出意外,请进行统一构建,以便在进行错误跟踪时,您不必担心服务器之间的不一致.
此外,如果您可以轻松地在构建和创建它的源之间进行映射,则无需将构建版本置于版本控制中.
在我工作的地方,我们的部署过程如下.(这是在Linux上,与Tomcat一起使用.)
测试更改并检查Subversion.(不一定按照这个顺序;我们不要求提交代码进行测试.我是唯一的全职开发人员,因此SVN树本质上是我的开发分支.您的里程可能会有所不同.)
将JAR/WAR文件复制到以Subversion修订版号命名的共享目录中的生产服务器.Web服务器只具有读访问权限.
部署目录包含指向修订版目录中文件的相对符号链接.这样,目录列表将始终显示生成运行版本的源代码版本.部署时,我们更新的日志文件只是目录列表.这使得回滚变得容易.(但有一点问题; Tomcat会根据真实文件的修改日期检查新WAR文件,而不是符号链接,因此我们必须在回滚时触摸旧文件.)
我们的Web服务器将WAR文件解压缩到本地目录中.该方法是可扩展的,因为WAR文件位于单个文件服务器上; 我们可以拥有无限数量的Web服务器,只进行一次部署.
京公网安备 11010802040832号 | 京ICP备19059560号-6 