我们有以下问题。开发人员经常需要对我们的 Web 应用程序进行小的更改。当我说小时，我的意思是更正网页上的拼写或类似内容。在这种情况下，生成和重新部署战争档案可能会很慢而且成本很高。
我们如何以增量方式自动化和安装更改？例如，生成新的爆炸战争，将文件与生产中的爆炸战争进行比较，然后在生产中仅替换受更改影响的文件：.jsp .html .class 等。
这个不用热部署，重启服务器就可以了。我希望避免的是必须复制和部署大小为 80Mb 的战争。有时连接速度很慢，对 Web 应用程序进行如此微小的更改（例如简单的拼写更正）可能需要数小时。
我们使用 Maven 来自动化我们的构建过程。关键问题是自动化整个过程，以便我可以确定我的 Subversion 中的应用程序 v2.2.3 正是我在增量部署后在生产中拥有的。
很难说。您当然可以在扩展的 web 应用程序中替换单个类文件，但这通常是个坏主意，而且您看不到很多人这样做。
原因是当您进行小的更改时，越来越难以发现生产和开发之间的差异。您发送错误的类文件并破坏生产服务器的机会随着时间的推移而增加。
当您说文本更改时，将文本资源与war文件分开是不是一个想法？这样，不仅开发人员，甚至客户都可以轻松添加/更改翻译。
对客户而言，这很重要，但从技术上讲，在慢速线路上进行 80MB 部署以修复小错字是很愚蠢的。
您还可以尝试查看您的构建/交付周期并增加测试工作以防止这些小的更改。
希望这可以帮助。
我们过去一直在做这种事情。我们在一家银行工作，有时法律用语或条款和条件需要在今天（或更通常是昨天）进行更改。
我们做了两件事来帮助我们快速部署。我们有一个很好的变更控制和构建过程。我们可以更改和部署我们喜欢的任何版本。我们还有一个很好的测试套件，我们可以使用它轻松测试更改。
第二个更有争议。我们所有的 html 都作为单独的文件部署在服务器上。没有战争。因此，当出现需要快速更改文本的情况时，我们可以做到。如果 Java 需要更改，我们总是会进行 FULL 构建和部署。
我不建议这样做，但这对我们的情况有好处。
WAR 的重点是让所有东西都同时部署。如果您使用的是 WAR，这意味着您希望一次部署它。
一个建议是不要经常进行此类更正（每周一次？）。那么你就没有那么痛苦了。
您可以将主战争部署在正在运行的服务器可以访问它的地方，而不是将战争文件部署到各个服务器，您可以使用 rsync 和 perl 来确定主战争中的任何文件是否有更改，然后将它们分发到服务器并执行重启。
目前我在远程服务器上安装了 SVN，所以如果是一个简单的 udate，你可以只更新单个文件。传输大的 WAR 文件是非常不切实际的。
您可以使用 putty / plink [如果您使用 Windows] 通过在本地计算机上创建一个简单的脚本并在远程计算机上创建另一个脚本来自动化单击部署。
目前我有一个 DEVELOPMENT SVN 和一个 LIVE SVN。ANT 构建将 DEV 合并到 LIVE 并再次提交回 LIVE 存储库。在那个阶段，远程服务器可以执行 SVN UP，您将自动获得请求的文件。
您可以进一步改进更新脚本以在某些类发生更改时重新启动服务器，并且在更新脚本/JSP 的情况下不重新启动。
通过这种方式，您还可以选择回滚到以前的版本，以确保您始终拥有一个正常工作的 Web 应用程序。
为了改进合并 SVN 的过程，这个工具非常有用。：http ://www.orcaware.com/svn/wiki/Svnmerge.py
通常的答案是使用持续集成系统来监视您的颠覆并构建工件并部署它们——您只希望您的 Web 应用程序即使在重新部署后也能正常工作。问题是这对你来说是否足够快？
我认为这个问题没有一个直接的答案。吨
这里的关键是模块化——我认为目前 Java 应用程序不能很好地解决这个问题。您可能想查看 OSGi 或动态模块，尽管我不确定它们在这个问题上的效果如何。
我见过人们将类放到应用程序服务器/servlet 容器中的解决方案，我不同意它，但它似乎确实有效……但我确信有恐怖故事！
Maven 通过将应用程序拆分为模块确实使事情变得更容易，但是如果您这样做并独立部署模块，您需要确保各种版本在测试环境中一起运行良好......
另一种方法是根据功能对应用程序进行分区，并在各种服务器上托管单独的功能，例如：
分区使部署应用程序变得更容易，但是您必须再次确保您的模块首先可以很好地协同工作。希望有帮助。
我以前也有过类似的情况。这确实是一个关注点分离问题，而且不是很直接。您需要做的是将文本与模板/HTML 页面分开。
我们通过将文本放入数据库表中并将该表用作消息资源来解决此问题 - 与人们使用 myMessages.properties 进行国际化 (i8n) 的方式相同。这为您提供了两个优势，您可以 i8n 文本，并立即轻松地在 prod 中进行更改，而无需代码部署。我们还缓存了表以确保性能不会受到太大影响。
不是所有人的解决方案，但它确实对我们非常有效。