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

Question

我希望能获得一些指导，了解如何最好地推广建筑物通过它的环境。

我们有三个环境：DEV、STAGING和PROD。

DEV Jenkins构建正在运行持续集成设置中，当代码被检入到子版本控制时，Jenkins将运行一个新的构建（清理、编译、测试、部署）。

麻烦的是当涉及到STAGING和PROD时。

想法是能够手动将成功的DEV构建推广到STAGING。 STAGING构建将检出DEV的SVN修订号，构建、测试、部署到staging，最后在SVN中创建一个分支。

最后，发布经理可以手动将STAGING构建推广到PROD。 PROD构建将从先前的STAGING构建检出分支，在PROD中进行部署，并标记该分支为发布。

我已经尝试使用Promotion Builds插件和Parameterized Trigger插件的组合，但没有成功。似乎无法将Subversion修订号从DEV构建传递到STAGING构建。

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

- Benny

Answer 1

另一种方法是利用Jenkins提供的工件存储结合Copy Artifact Plugin。

1. 当构建完成时，您可以指示Jenkins将应用程序持久化，以压缩的zip / tar.gz格式或作为应用程序包（jar / war）
2. 触发下游作业并使用Copy Artifact从上游作业检索记录的工件（或使用参数化构建）
3. 根据需要部署/解压工件-构建shell脚本/ maven deploy？
4. 使用与步骤1中创建的相同源码/二进制文件重新测试应用程序
5. 如有必要，请重复进行PROD

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

- Toby Jackson

Answer 2

在这种情况下，为什么需要回到svn中标记分支？我们不使用svn，但是在使用TFS时，当Hudson/Jenkins获取代码时，它检索到的变更集号码会出现在构建日志中。因此，我们知道构建来自哪段代码，并且可以随时返回。然后，我们使用Hudson将构建从一个环境推广到另一个环境，源代码控制系统不需要知道代码部署在哪里。

- Tom DAurizio

---

当你说“使用Hudson在环境之间推广构建”时，这是否意味着你已经配置了单独的项目，知道如何获取构建的工件？还是重新编译代码的项目？我认为，理想情况下，会有一个插件，可以在给定工件上添加图标，从而允许您通过现有的构建项目进行部署。 - Matt Felzani

@Tom DAurizio：是否可以将构建好的代码部署到不同的环境中？ - ArunRaj

Answer 3

如果有必要存储 SVN 版本 ID，那么可以在 DEV 任务中添加构建步骤将其复制到文件中。操作类似如下代码所示:

echo %SVN_REVISION%>revision.ini

或者类似这样：

echo MY_SVN_REVISION=%SVN_REVISION%>revision.ini

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

- Jason Swager