Jenkins - 将构建推广到不同的环境答案

【问题标题】：Jenkins - Promoting a build to different environmentsJenkins - 将构建推广到不同的环境
【发布时间】：2011-10-10 00:01:42
【问题描述】：

我希望获得一些关于通过其环境推广构建的最佳方式的指导。

我们有 3 个环境，DEV、STAGING、PROD。

DEV Jenkins 构建在持续集成设置中运行，当代码签入到 subversion 时，Jenkins 将运行新构建（清理、编译、测试、部署）。

棘手的一点是在 STAGING 和 PROD 方面。

我们的想法是能够手动将成功的 DEV 构建提升到 STAGING。 STAGING build 会检查 DEV 的 SVN 修订号，构建、测试、部署到 staging，最后在 SVN 中创建一个分支。

最后，发布经理可以手动将 STAGING 构建升级为 PROD。 PROD 构建将检查先前 STAGING 构建的分支，部署到 PROD 并将分支标记为发布。

我尝试结合使用 Promotion Builds Plugin 和 Paramterized Trigger Plugin，但没有成功。 Subversion 修订号似乎没有在 DEV 构建和 STAGING 构建之间传递。

是否有人对他们在多个环境中推广构建的过程有任何指导？

【问题讨论】：

【解决方案1】：

另一种方法是利用 Jenkins 提供的 Artifact 存储以及 Copy Artifact Plugin。

这种方法允许您对工件进行指纹识别，因此 Jenkins 将在 UI 中将构建链接在一起，并允许更正式的签核。

【讨论】：

【解决方案2】：

在这种情况下，为什么需要回过头来在svn中给分支打上标签呢？我们不使用 svn，但是使用 TFS，当 Hudson/Jenkins 获取代码时，它检索到的变更集编号在构建日志中。所以我们知道构建来自什么代码，并且可以随时返回。

然后我们使用 Hudson 将构建从一个环境推广到另一个环境，源代码控制系统不需要知道代码部署在哪里。

【讨论】：

当您说“使用 Hudson 将构建从一个环境提升到另一个环境”时，这是否意味着您配置了知道如何获取构建工件的单独项目？还是重新编译代码的项目？我在想，理想情况下会有一个插件，可以在给定的工件上添加图标，允许您通过现有的构建项目进行部署。
@Tom DAurizio：是否可以将构建的代码部署到不同的环境中。

【解决方案3】：

如果绝对需要存储 SVN 修订 ID，则将构建步骤添加到您的 DEV 作业，将其复制到文件中。像这样的：

echo %SVN_REVISION%>revision.ini

或类似的东西：

echo MY_SVN_REVISION=%SVN_REVISION%>revision.ini

然后是工件revision.ini。在进行 STAGING 构建时，使用 Copy Artifact 插件（如之前的用户所述）来检索特定于构建的 revision.ini 文件并将其加载到变量中。然后在命令行调用“svn”中使用该变量来构建标签。

【讨论】：