Java Web应用程序—WAR的替代部署策略—独立于完整的代码基修补程序管理UI更改

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

问题：对JavaWeb项目的UI更改可能会非常繁琐和耗时，因为每个web应用程序文件都包含在WAR中

我提出的解决方案是：将JSP、CSS、JS和标记与应用程序代码库分开管理，就本问题而言，我将其定义为：

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

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

用例-网站所有者正在进行推广，他有一个奇特的图形链接到纯HTML信息页面，并希望将其添加到主页

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

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

$ staging - > ./rollbackView -mostRecentBackup

用户界面的人检查了网站，一切都回来了，好像他从来没有碰过它。。现在，他更加小心地添加了图形和HTML，意识到他之前已经删除了一个JSP自定义标记。现在，QA，不管项目是什么，查看站点，运行selenium，不管什么。一切看起来都很棒。开发人员获得了发布更改的批准

$ production - > ./updateProductionView

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

现在开发人员想要创建一个补丁，允许一些很酷的东西，他更新他的项目，新的视图文件就出现了。也许这是不可能的，但他可以运行一个脚本，或者使用第二个源存储库（如Mercurial）来管理视图（ideas？），并且他有他需要的项目和视图文件。他根据自己的需要对源代码和视图进行更改。现在已经完成了，他可以签入自己的更改，并在登台时将WAR带到一个目录中

$ staging - > ./deployStaging -overwriteView

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

$ staging - > ./deployProduction

这里有一个完整的部署，应用程序版本现在是V1.1，每个人都很高兴

我的问题是:

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

我正在寻找一些脚本的想法，这些脚本允许备份登台web文件，甚至希望能够将其提交到主项目中，也可以使用脚本

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

---

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

如果可以选择远离JSP，您可以使用模板系统（例如），并将这些资源存储在部署的war之外，例如文件系统或关系数据库中。

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

---

我想知道您为什么要保留一个单独的存储库。我们经常这样做——只发送JSP补丁——因此整个应用程序代码（EJB/SpringBeans等）在预生产（登台）环境中总是最新的。UI开发人员标记每一个补丁，我们从版本控制中提取所有JSP by fix标记以投入使用。这是一个很好的系统，这里唯一的问题是，我们的UI人员虽然能够在JSP中工作，但不能在他们的系统上使用Java开发环境，这对他们来说简直太过分了。让他们在测试环境中修改实时JSP意味着他们可以实时看到他们的UI更改，就像他们在更改生效时看到的一样。这有意义吗？您的应用程序服务器能否处理爆炸战争，即直接处理文件而不是归档文件？我研究了velocity，它有自己的表达式语言，这一事实使得它的实现有太多的变化，我对我的JSP非常满意，一个对服务器端语言知之甚少的UI开发人员可以很容易地看到正在发生的事情，而只需很少的解释。他们不只是使用JSP标准，这太糟糕了，因为我对在中使用它们很感兴趣

$ staging - > ./deployStaging -overwriteView

$ staging - > ./deployProduction