我在客户端服务器计算机上的tomcat6上部署了grails应用程序，但是应用程序仍然需要很多修复，因此客户端计算机上创建或缺少每个bug的功能，我创建一个补丁并通过ftp上的ftp传递给客户端。 .gz文件将替换已部署的文件夹。
我无法发送完整的.war文件，因为应用程序很大（约80M），因此发送更改.class文件是我唯一的选择。但创建补丁的过程太耗时，特别是在重建项目，清理目标文件夹并开始编译项目中的所有文件。之后，我使用新的目标/类文件夹上的比较文件夹应用程序搜索不同的.class文件，与旧的目标/类文件夹进行比较，然后将其发送给客户端。
创建战争过程真的花了很多时间来修复一个小问题，是否有一种方法在编译代码上获得不同的.class更简单？因为我需要在2-3天创建补丁，用于修复客户报告的常规内容。
感谢，
答案 0 :(得分：2)
我们所做的一切都很干净
grails clean
然后创造一个没有罐子的战争
grails war --nojars
上传时间为5mb（需要一段时间），但速度超过50 / 80MB。如果我们添加一个插件tc，那么我们需要完成一个完整的上传/构建。
然后我们将爆炸战争的顶部解压缩并重新启动tomcat / jetty /等。
希望这有帮助。
答案 1 :(得分：2)
我们构建WAR文件，然后在本地解压缩并将本地爆炸的WAR（使用RSync）与服务器上的爆炸WAR同步（使用开发人员Windows机器上的Cygwin）。 RSync协议非常有效，因此通过Internet部署非常快，但WAR文件生成仍然需要很长时间:(
我们在开发人员机器和服务器上都有脚本，因此如果您对WAR构建时间进行折扣，我们的部署机制将非常轻松。另外，我们没有rsync直接进入生产目录，我们等到rsync完成后再在服务器上运行一个脚本，这个脚本也备份了以前的生产版本，万一出现了可怕的错误。
答案 2 :(得分：0)
无法为Grails应用程序创建补丁。如果您要交付应用程序的人愿意将库存放在tomcat共享库目录中，请参阅this link以获取有关如何将war文件大小减少到几个而不是80的信息。
答案 3 :(得分：0)
从技术上讲，还有另一种在运行时更改代码的方法：它是Groovy，所以你可以在运行时重新分配类方法，比如
MyDomainClass.metaclass.'static'.'method' = { some closure; }
尽管如此，它非常危险并且不能重新启动。
你可以在Groovy Web Console中完成。暴露Web控制台是另一个很大的安全漏洞。
我建议您将类检查到源代码控制中，并在目标计算机/目标网络中构建。 SVN流量被压缩，因此交付时间不会很长。
答案 4 :(得分：0)
另一个替代方案是使用源代码控制（像mercurial或git这样的DVCS很适合这个），并让客户端为您想要提供的代码的任何分支提取只读版本。然后有一个构建脚本（gradle / ant / gant），可以下载/安装grails并编译生产war文件并进行部署。