Question

我对此问题进行了大量编辑，因为回复表明我不清楚

问题：对Java Web项目进行UI更改可能会非常繁琐且耗时，因为每个Web应用程序文件都包含在WAR中

我提出的解决方案：从应用程序代码库中单独管理JSP，CSS，JS和标签，为了这个问题，我将其定义为：

所有Java源代码
使用编译Java的自定义标记库（扩展TagSupport）
Spring配置文件
Web.xml中
罐的

+ Source
+ WEB
   - WEB-INF
      - JSP
      - Tags
      - lib
   - HTML
   - CSS
   - JS

如果在主要的初始发布和维护周期之后，对视图文件的更改可以被视为与源更改的不同类型的发布，那将是更好的。源更改将正常提交，应用程序版本将更改。但是，可以在内部可查看的测试环境中对CSS / JS / HTML甚至JSP进行更改，以测试新外观，添加链接等。从技术上讲，甚至可以添加一个JSP，只要控制器（像我的那样）可以配置为显示新的JSP而不需要任何Source修改，就可以添加页面而无需任何部署。

使用案例 - 该网站的所有者正在投放促销活动，他有一个花哨的图片链接到信息纯HTML页面，并希望将其添加到主页。

现在想象一下这个工作流程： UI dev打开Dreamweaver并可以FTP进入Staging（暂存可能是一个坏名称，但基本上是一个实时测试服务器）。他可以看到：

   - JSP
   - Tags
   - HTML
   - CSS
   - JS

现在，他带来了包含有关信息的HTML文件，并将其添加到HTML目录中。然后他进入JSP / home.jsp并找到在右栏上呈现广告的组件，在其正下方，他添加了他的漂亮图像，保存他的更改，打开他的浏览器并转到实时测试URL。他看到了他的形象，但该组件不再呈现广告。哎呀，他称开发人员和开发人员说没问题

$ staging - > ./rollbackView -mostRecentBackup

UI人检查网站，一切都回来了，就像他从未碰过它一样..现在他更加谨慎地添加了他的图形和HTML，意识到他之前切断了JSP自定义标签。现在，质量保证，无论该项目是什么，看看该网站，运行selenium，无论如何。一切看起来都很棒。开发人员可以发布更改

$ production - > ./updateProductionView

脚本检查应用程序版本，确保它们完全相同，然后复制视图文件。现在是8:45，网站所有者（我们内部人员）非常高兴他的新想法在当天的前15分钟实施了

现在开发人员想要创建一个允许一些很酷的补丁，他更新他的项目，并且存在新的视图文件。也许这是不可能的，但他可以运行一个脚本，或使用像Mercurial这样的第二个源代码库来管理视图（想法？），并且他拥有他需要的项目和视图文件。无论他需要什么，他都会对源头和观点做出改变。现在完成后，他可以检查他的更改并将WAR带到Staging上的目录

$ staging - > ./deployStaging -overwriteView

部署完整的战争，现在JSP就是他在项目中所拥有的。如果UI人员对分段进行了更改，它们将被覆盖（可能会备份？）。他可以省去'-overwriteView'标志，视图文件将保持不变。此时已经运行了完整的QA回归，集成和单元测试，是时候修补主应用程序了

$ staging - > ./deployProduction

完全部署，应用程序版本现在是V1.1，每个人都很高兴

我的问题：

首先，有人做过这样的事吗？如果是这样，你能提出什么好的建议吗？开发在Windows上完成，但生产和登台服务器正在运行Unix。所有服务器都运行相同版本的Tomcat。

我正在寻找允许备份暂存Web文件的脚本的想法，并希望甚至可以提交到主项目，也可以采用

的脚本

什么被忽视了？我可以保持项目结构相同吗？这会导致CVS出现问题吗？

这里有什么不可能或技术上可行的吗？

Answer 1

您可以将UI资源指向其他文件夹吗？这样，您可以在测试服务器上设置一次符号链接，并允许UI开发人员操作“实时”文件。如果这些文件夹是源代码控制的，那么UI开发人员可以根据需要回滚自己的更改。

http://www.isocra.com/2008/01/following-symbolic-links-in-tomcat/

Answer 2

如果从JSP切换是一个选项，您可以使用模板系统（例如Velocity或Freemarker）并将这些资源存储在部署的战争之外，文件系统或关系数据库中例如。

Java Web应用程序 - WAR的替代部署策略 - 与完整代码基础修补程序分开管理UI更改

2 个答案: