1
1
我们以前总是做这种事。我们在一家银行工作,有时法律术语或条款和条件会发生变化,今天(或更通常是昨天)需要改变。 我们做了两件事来帮助我们快速部署。我们有一个良好的变更控制和构建过程。我们可以更改和部署任何我们喜欢的版本。我们也有一个 好的 测试套件,使用它我们可以轻松地测试更改。 第二个更具争议性。我们所有的HTML都作为单独的文件部署在服务器上。没有战争。因此,当情况出现时,我们需要迅速改变一些文本,我们可以做到。如果Java需要改变,我们总是做一个完整的构建和部署。 这不是我推荐的,但对我们的情况有好处。 战争的关键是使所有的东西都能同时部署。如果你正在使用一场战争,那意味着你希望它能同时部署。 一个建议是不要经常(一周一次?)那你就没有那么多痛苦了。 |
2
1
很难说。当然,您可以在一个分解的webapp中替换单个类文件,但这通常是一个坏主意,而且您不会看到很多人这样做。 原因是,当你做一些小的改变时,就越来越难发现生产和开发之间的差异。随着时间的推移,发送错误的类文件并破坏生产服务器的可能性会增加。 当您说文本更改时,是否建议将文本资源与war文件分开?这样,不仅开发人员,甚至客户都可以轻松地添加/更改翻译。 对客户来说,这很重要,但从技术上讲,在一条慢线上部署80MB来修复一个小的打字错误是愚蠢的。 您还可以尝试查看构建/交付周期,并增加测试工作以防止这些小的更改。 希望这有帮助。 |
3
0
您可以将主war部署在运行中的服务器可以访问的地方,而不是将war文件部署到各个服务器,您可以使用rsync和perl来确定主war中是否有任何文件更改,将它们分发到服务器并执行重新启动。 |
4
0
|
5
0
目前我在远程服务器上安装了SVN,所以在简单的udate情况下,您可以只更新单个文件。传输大型战争文件是非常不切实际的。 通过在本地计算机上创建一个简单的脚本,或者在远程计算机上创建另一个脚本,您可以使用putty/plink[如果您使用的是Windows]自动执行到一次单击部署。 目前我有一个开发SVN和一个实时SVN。Ant构建正在将dev合并为live,并再次提交回live存储库。在这一阶段,远程服务器可以启动SVN,您将自动获得请求的文件。 您可以进一步改进更新脚本,以便在某些类发生更改时重新启动服务器,而在更新脚本/jsp时不重新启动。 这样,您还可以选择回滚到以前的版本,以确保您的Web应用程序始终正常工作。 为了改进SVN的合并过程,该工具非常有用。: http://www.orcaware.com/svn/wiki/Svnmerge.py |
6
0
通常的答案是使用一个持续集成的sstem,它监视您的Subversion并构建工件并部署它们——您只是希望Web应用程序在重新部署之后也能正常工作。问题是这对你来说是否足够快? |
7
0
我觉得这个问题没有一个直接的答案。T 这里的关键是模块化——目前我认为Java应用程序无法很好地解决这个问题。您可能想看看OSGi或动态模块,但是我不确定它们在这个问题上有多有效。 我看到过一些解决方案,人们将类放到应用服务器/servlet容器中,我不同意,但它似乎确实有效…不过,我肯定有恐怖故事! Maven当然可以通过将应用程序拆分为模块来简化工作,但是如果您这样做并独立地部署模块,那么您需要确保各种版本在测试环境中能够很好地协同工作以开始…… 另一种选择是根据功能对应用程序进行分区,并在不同的服务器上承载不同的功能,例如:
分区使部署应用程序更加容易,但同样,您必须首先确保模块能够很好地一起工作。希望有帮助。 |
8
0
我以前也有过类似的情况。这确实是一个关注点分离的问题,并不是太直截了当。您需要做的是将文本与模板/html页面分开。 我们通过将文本放在数据库表中,并将该表用作消息资源来解决这个问题——就像人们使用mymessages.properties进行国际化(i8n)一样。这给了您两个好处,您可以在文本中i8n,并且可以在不部署代码的情况下立即轻松地在prod中进行更改。我们还缓存了表以确保性能不会受到太大影响。 不是所有人的解决方案,但它对我们确实很有效。 |