使用 Grails 持续交付答案

【问题标题】：Continuous Delivery with Grails使用 Grails 持续交付
【发布时间】：2013-07-31 13:32:27
【问题描述】：

背景：

我的团队一直在使用 Jenkins 为我们的 Grails 应用程序运行持续集成 (CI)。我们正试图通过设置部署管道并将按钮部署到多个环境（Dev、Itg、Prod）来更接近Continuous Delivery。我们曾尝试使用 Jenkins Tomcat 插件来部署我们的代码，但在 Tomcat 上偶尔会遇到 PermGen 问题，并且必须在部署后手动重新启动它。

问题：

Jenkins 是否适合使用 Grails 进行自动化部署？
我们如何自动部署到 Tomcat 而无需事后手动重新启动它？

【问题讨论】：

标签： tomcat grails jenkins continuous-delivery

【解决方案1】：

我认为没有人能说 Jenkins 是否是“正确”的工具，但它是一个很好的工具。
当您热部署到 Tomcat 时，它的 PermGen 几乎不可避免地会增长。重新启动是处理此问题的最简单方法。有关更多信息，请参阅What makes hot deployment a "hard problem"? 等其他问题。您可以使用 Post Build Task 在 Jenkins 服务器上运行 shell 脚本来部署 war 并重新启动 Tomcat。

【讨论】：

【解决方案2】：

我们使用 grails、tomcat 和弹性负载均衡器，并通过 AWS 基础设施编写脚本实例启动/配置/部署。 S3 存储桶包含我们的 Jenkins 服务器作为我们配置的插件的一部分放置在那里的 war 文件。这是由内部版本号和 Jenkins 作业名称控制的，因此我们为每个环境都有一个。厨师脚本将我们的依赖关系和战争拉入实例并完成所有实际工作，而我们的 Jenkins 运行编排脚本循环并在每个成功阶段休眠，直到新实例完全启动并通过负载均衡器健康检查，此时我们停止旧实例（负载均衡器排向新实例）。如果出现任何故障或超时，我们会在关闭新实例后使 Jenkins 作业失败。为了遵循这种方法，我们的应用程序中没有共享状态，我们通过 grails spring 安全集成使用 memcached (elasticache) 作为我们的会话存储。

【讨论】：

【解决方案3】：

在我看来（诚然有偏见）Jenkins 并不是用来执行部署的。它不是那样设置的。就剪刀并不意味着剥橘子而言，Jenkins 不是进行部署的正确工具。但无论如何它都会完成这项工作。

【讨论】：