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