问题描述
我希望获得一些关于通过其环境推广构建的最佳方式的指导.
I was hoping for some guidance on the best way to promote a build through its environments.
我们有 3 个环境，DEV、STAGING、PROD.
We have 3 environments, DEV, STAGING, PROD.
DEV Jenkins 构建在持续集成设置中运行，当代码签入 subversion 时，Jenkins 将运行新构建(清理、编译、测试、部署).
The DEV Jenkins build is running in a continuous integration set-up, as code is checked in to subversion, Jenkins will run a new build (clean, compile, test, deploy).
棘手的一点是在 STAGING 和 PROD 方面.
The tricky bit is when it comes to STAGING and PROD.
这个想法是能够手动将成功的 DEV 构建提升到 STAGING.STAGING build 会检查 DEV 的 SVN 修订号，构建、测试、部署到 staging 并最终在 SVN 中创建一个分支.
The idea was to be able to manually promote a successful DEV build to STAGING.STAGING build would check out the DEV's SVN Revision number, build, test, deploy to staging and finally create a branch in SVN.
最后，发布经理可以手动将 STAGING 构建升级为 PROD.PROD 构建将检查先前 STAGING 构建的分支，部署到 PROD 并将分支标记为发布.
Lastly the release manager could manually promote the STAGING build to PROD.PROD build would check out the branch from the previous STAGING build, deploy to PROD and tag the branch as a release.
我尝试结合使用 Promotion Builds Plugin 和 Paramterized Trigger Plugin，但没有成功.Subversion 修订号似乎没有在 DEV 构建和 STAGING 构建之间传递.
I have tried to use a combination of the Promotion Builds Plugin and the Paramterized Trigger Plugin but with no luck. The Subversion Revision number doesn't seem to get passed between DEV build to STAGING build.
是否有人对他们在多个环境中推广构建的过程有任何指导?
Does anyone have any guidance on their process to promote a build through multiple environments?
推荐答案
在这种场景下，为什么需要回过头来在svn中给分支打标签呢?我们不使用 svn，但使用 TFS，当 Hudson/Jenkins 获取代码时，它检索到的变更集编号在构建日志中.所以我们知道构建来自什么代码，并且可以随时返回.
In this scenario, why do you need to go back and label the branch in svn? We don't use svn, but w/ TFS, when Hudson/Jenkins gets the code, the changeset number it has retrieved is in the build log. So we know what code the build came from, and could get back to it at any time.
然后我们使用 Hudson 将构建从一个环境推广到另一个环境，源代码控制系统不需要知道代码部署在哪里.
Then we promote the build from environment to environment using Hudson, the source control system doesn't need to know where the code is deployed.
这篇关于Jenkins - 将构建推广到不同的环境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！