我希望能够就通过其环境促进构建的最佳方式提供一些指导 .
我们有3个环境，DEV，STAGING，PROD .
DEV Jenkins构建在持续集成设置中运行，因为代码被检入到subversion，Jenkins将运行新构建（清理，编译，测试，部署） .
当谈到STAGING和PROD时，棘手的一点是 .
我们的想法是能够手动将成功的DEV构建推广到STAGING . STAGING构建将检查DEV的SVN版本号，构建，测试，部署到分段，最后在SVN中创建分支 .
最后，发布经理可以手动将STAGING构建推广到PROD . PROD构建将从先前的STAGING构建中检出分支，部署到PROD并将分支标记为发布 .
我试图使用Promotion Builds插件和Paramterized Trigger插件的组合，但没有运气 . Subversion修订版号似乎没有在DEV构建到STAGING构建之间传递 .
有没有人对他们通过多种环境推广构建的过程有任何指导？
3 回答
在这种情况下，为什么需要返回并在svn中标记分支？我们不使用svn，但是使用w / TFS，当Hudson / Jenkins获取代码时，它检索到的变更集编号在构建日志中 . 所以我们知道构建来自哪些代码，并且可以随时回复它 .
然后我们使用Hudson促进从环境到环境的构建，源代码控制系统不需要知道代码的部署位置 .
另一种方法是利用Jenkins提供的Artifact存储加上Copy Artifact Plugin .
构建完成后，您可以指示Jenkins保留您的应用程序，可以是压缩的zip / tar.gz，也可以是应用程序包（jar / war）
触发下游作业并使用复制工件从上游作业中检索记录的工件（或使用参数化构建）
根据需要部署/解压缩工件 - 构建shell脚本/ maven部署？
使用与步骤1中创建的源/二进制文件相同的源/二进制文件重新测试应用程序
根据需要重复PROD
这种方法允许您指纹工件，因此Jenkins会在UI中将构建链接在一起，并允许更正式的签名 .
如果绝对需要存储SVN版本ID，则向DEV作业添加一个构建步骤，将其复制到文件中 . 像这样的东西：
或类似的东西：
然后是artifact revision.ini . 在进行STAGING构建时，使用Copy Artifact插件（如前一个用户所述）检索特定于构建的revision.ini文件并将其加载到变量中 . 然后在命令行调用“svn”中使用该变量来构建标记 .