为 Grails 构建自动化、代码审查和部署系统
虽然这个问题在技术上可以应用于任何语言/框架，但我想知道构建、审查和部署 Grails 应用程序的一些行业最佳实践是什么。
根据我个人的经验，我使用 Groovy 脚本，利用 AntBuilder 进行构建，跳过审查并使用 ssh/scp 将战争转移到应用程序服务器。由于遗留问题，我们使用 CVS 和 git 的组合。
是否有一个自动化系统或工作流程模型可以让我以最少的时间和资本投资来完成三件事：构建、审查和部署。
我听说过的一个可能的场景是使用 Jenkins 来构建，Gerrit 来审查，但我似乎错过了最后一部分 - 如何自动部署？
Although this question could technically be applied to any languages/framework, I would like to know what some of the industry best practices are for building, reviewing and deploying a Grails application.
From my personal experience, I use a Groovy script that utilizes AntBuilder to do the build, skip the review and use ssh/scp to move the war over to the application server. Because of legacy issues we use a combination of CVS and git .
Is there a automated system or workflow model that will allow me to do three things, build , review and deploy with the least amount of overhead investment in time and capital.
One possible scenario I have heard of is using Jenkins to build, Gerrit to review , but I seem to be missing the last part - how to automatically deploy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 Jenkins 进行操作 - 使用标准作业进行每晚构建，并使用参数化的 jenkins 作业部署来测试环境（将环境名称作为参数）。
Do it with Jenkins - nightyly builds using a standard job and deployments to test environments with parameterized jenkins jobs (given the environment name as a parameter).
通常使用外部配置文件。通过这种方式，您可以一次性构建并在您的环境中推广 war 文件。任何特定于环境的配置都在外部文件中设置。
一直使用 Hudson / Jenkins 来完成所有这些工作。 1 个连续运行测试的作业。一项工作是对工件进行夜间/头部/标签构建。将文件复制到不同部署服务器的另一个作业或一组作业。然后使用服务器上的脚本来实际推送代码。 （最后一步可以很容易地通过 Jenkins 命令启动）
最近一直在尝试一个我似乎喜欢的促销插件。当您升级代码时，它会启动将文件复制到正确服务器的作业，并“标记”Jenkins 构建，让您知道升级了哪些构建号。
Usually use external configuration files. This way you can make your build one time and just promote the war file through your environments. Any environment specific configs are set in your external files.
Have always used Hudson / Jenkins to do all of this. 1 job to continuously run tests. One job to do a nightly / head / tag build of your artifacts. Another job or set of jobs that copies the files to the different deployment servers. Then use a script on the server to actually push the code live. (This last step could easily be kicked off by a Jenkins command)
Lately have been trying out a promotion plugin that I seem to like. As you promote the code, it kicks off the jobs to copy the files to the correct servers, and "tags" the Jenkins build to let you know which build number(s) were promoted.