我们已经开始使用 Hudson，目前的工作流程是：
本地结帐 > 代码 > 运行测试 > 更新 > 运行测试 > 提交
而不是轮询，Hudson 只是坐在那里，直到我们实例化一个构建。然后它：
在本地结帐 > 运行 Phing 脚本
然后 Phing 脚本：
svn 导出最新版本 > 运行测试（如果成功）> 生成报告等.. > 压缩导出 > scp 到生产服务器 > .. 变魔术让网站上线...
这一切都很好，花花公子，但它并没有真正让我们有能力进行任何类型的“分期”质量检查，并且每个构建都会构建 repo 头修订版。理想情况下，我们希望 Hudson 轮询或使用提交后挂钩构建每个提交，并且：
在本地结帐 > 运行 Phing 任务以运行测试，如果成功，则生成报告等。
然后能够手动实例化一个自动化部署（通过 Phing 任务），以“从每个特定构建中分阶段 QA 环境或生产。并非每个提交都将部署到 QA。
这个工作流程是否可以通过 Hudson 实现，或者我们是否需要在之后手动运行我们的部署 Phing 任务。
我将构建/测试作业 (job1) 和部署作业 (job2) 分开。Job1 在每次提交后在主干上运行（Hudson 民意调查，但提交后挂钩也可以工作）。它还归档构建工件。Job2 将手动启动。它从 job1 获取 build_number 作为构建参数（我喜欢 run 参数）并将工件从 job1 下载到它自己的工作区中。他们运行部署。在您的情况下，我将添加另一个参数（选择参数）以确定您要部署的环境。
使用 description setter 插件，您可以从 job1 和环境中打印出运行编号，并且您可以在作业历史记录中轻松查看什么构建部署到什么环境。
我最终做了类似于 Peter Schuetze 建议的事情。然而，我只使用了唯一的工作。我使用 3 个构建参数，部署（布尔）、环境（选择）和修订（文本）。然后，我将我的 Phing 脚本更改为仅在 deploy 参数为 true 时进行部署，在这种情况下，它会将指定的修订版部署到指定的环境。默认部署为假，修订为头，环境为暂存。现在，当 Hudson 轮询 svn 时，它发现 deploy 参数为 false 并绕过部署任务。
我不完全清楚你想要实现什么，但我想知道你是否在使用Phing插件？也许您想要的东西目前无法通过 Hudson 实现，并且可能需要更改您的开发流程才能实现。