使用 Hudson 将构建与部署分开
我们已经开始使用Hudson，目前的工作流程是:
We have started using Hudson, and the current workflow is:
在本地结帐 > 代码 > 运行测试 > 更新 > 运行测试 > 提交
checkout locally > code > run tests > update > run tests > commit
Hudson 只是进行轮询，直到我们实例化构建为止.然后:
Rather that polling, Hudson simply sits there until we instantiate a build. It then:
在本地结帐 > 运行 Phing 脚本
checkout locally > run Phing script
然后是 Phing 脚本:
The Phing script then:
svn export latest revision > 运行测试(如果成功) > 生成报告等. > 压缩导出 > scp 到生产服务器 > .. 施展魔法让网站上线...
svn export latest revision > run tests (if successful) > generates reports etc.. > compresses export > scp to production server > .. do magic to make site live...
这一切都很好，很漂亮，但是它并没有真正让我们有能力进行任何类型的分期"质量检查，并且每个构建都会构建 repo 头修订版.理想情况下，我们希望 Hudson 轮询或使用提交后挂钩构建每个提交，并且:
That all works fine and dandy, however it doesn't really give us the ability to any kind of of "staging" QA and every build builds the repo head revision. Ideally we would like Hudson to poll or use post commit hooks build each commit and:
在本地结帐 > 运行 Phing 任务以运行测试，如果成功，则生成报告等.
checkout locally > run Phing task to run tests and if successful, generates reports etc..
然后能够手动实例化一个自动化部署(通过 Phing 任务)，以从每个特定构建中分阶段 QA 环境或生产.并非每个提交都将部署到 QA.
Then be able to manually instantiate an automated deployment (via Phing task) to either "staging QA environment or production from with each specific build. Not every commit will be deployed to QA.
这个工作流程是否可以通过 Hudson 实现，或者我们是否需要在之后手动运行我们的部署 Phing 任务.
Is this work flow even possible from with Hudson, or are we going to need to manually run our deployment Phing tasks after.
推荐答案
我最终做了类似于 Peter Schuetze 建议的事情.然而，我只使用了唯一的工作.我使用 3 个构建参数，部署(布尔)、环境(选择)和修订(文本).然后，我将我的 Phing 脚本更改为仅在 deploy 参数为 true 时进行部署，在这种情况下，它会将指定的修订版部署到指定的环境.默认部署为假，修订为头，环境为暂存.现在当 Hudson 轮询 svn 时，它发现 deploy 参数为 false 并绕过部署任务.
I ended up doing something similar to Peter Schuetze suggestion. I used only the only job however. I use 3 build parameters, deploy (bool), environment (choice) and revision (text). I then altered my Phing scripts to only do deployments if the deploy parameter is true, in which case it will deploy the specified revision to the specified environment. By default deploy is false, revision is head and environment is staging. Now when Hudson polls svn, it sees the deploy parameter is false and bypasses the deployment tasks.
相关文章