我们最近将Hudson用于持续集成，并开始享受自动测试，静态分析等的好处。我们的下一步是让我们的繁琐的手动发布过程正在进行中。我设想的是一个两阶段的过程：
分支发布行。一旦我们的开发线稳定下来，我们就想分支。因为我们拥有低密度，高需求的用户，所以在正式发布之后通常会有一些活动，导致在发布行开始时进行一些停止和开发（我们不会想要阻止主线的开发）所以在方便的时候进行分支，然后允许稳定窗口（几小时到一天或两天）的做法是有道理的。 （这是在颠覆中完成的;通常我们在分支之前立即标记开发版本，然后分支，然后进行并行开发）
从分支中删除一个版本。目前涉及
所以要在Hudson中实现这样的事情，干净利落，我们怎么做：
执行来自Hudson的分支操作，该分支操作在给定新的发布分支名称的情况下对树进行分支，并生成新的Hudson作业以为该分支创建新的连续构建行。 （它接近现有-trunk配置的副本，但必须替换一些工作区名称和事物......）
逻辑属于哪里与Subversion交互？ （可以想象，可能是在ant脚本中;可能是一个单独的脚本; Hudson / plugins似乎也提供了一些逻辑？）
关于Hudson /子流程在写入模式下与repo对话时的用户/权限的想法吗？
如果第二阶段，上述问题也适用，我可以使用发布插件自动执行这样的逻辑吗？
我已经仔细阅读了Hudson和Release Plugin文档，但它相当不稳定，并且没有很多工作示例从端到端布局......
编辑添加： 我理解并期待“你考虑过Maven吗？”回应......我很欣赏它，我知道Maven可能是正确的长期解决方案，但是构建系统转换以及转移到Maven的精确限制和教育技术人员的所有方法和工作都是不可行的在短期内。据推测，有一种方法可以用蚂蚁和一点肘油脂来做到这一点......
答案 0 :(得分：1)
短期基于Ant的流程
鉴于你对Ant构建过程的承诺（除了你错过的好东西之外没有任何问题）我建议你镜像Maven方法，但是在Ant中做。所以要有一个彻底的read of this article that shows how to use SVNAnt。
长期理想的解决方案
正如@Peter Lawray所说，Maven是你的朋友。具体来看一下release插件，它将管理使用项目的“gold release”版本标记Subversion存储库的过程。基本上，你执行一个完整的构建（包括功能测试，如果你有他们）来验证你的工件，然后Maven标记你的Subversion repo，最后它运行你的项目pom.xml文件，并重新版本到一个新的水平up（作为快照）。
就构建过程而言，Hudson与Maven一起工作，并将按照您在Maven pom.xml中指定的顺序构建和测试工件（您的JAR，WAR，EAR等）。
如果您愿意，您可以选择SeleniumRC并提供多浏览器自动化功能测试环境。 Maven处理它从构建，到工件部署到构建服务器然后进行后续功能测试，并通过发布过程进行最终签名。
如果您有兴趣，我blogged a little about this。
答案 1 :(得分：1)
这是一个解决方案，直到你有maven到位。
我认为您应该创建一些脚本来完成所有工作（ant和/或批处理/ shell脚本）。看看Batch Task plugin。这允许您在作业的当前工作空间上运行发布。您的脚本旨在完成所有工作。您可以使用remote api设置当前作业的副本。如果环境变量（如JobName）不可用，则可能需要对作业名称进行硬编码（或在构建期间将其记录在工作区中的文件中）。最后，您将拥有更新的主干（开发行），新的发布行（在分支中）以及在发布分支上运行所有CI的作业。
答案 2 :(得分：0)
我不会将分支和标记作为构建的一部分，我会手工完成。这是（再次！）也许是一个哲学上的差异：我认为Hudson是一种获取某些代码行的当前状态并产生其工件的方法，而不是作为操作代码行的工具。它就像一个大型编译器，但不像IDE。
所以，我的过程看起来像（事实上，我们的过程确实如此）：
因此，设置新版本是开发人员/构建管理器任务，但实际构建版本是由Hudson完成的。
设置版本确实涉及手动工作，但你不能称之为繁琐 - 标记，分支，编辑几个文件，提交，创建作业和更改其分支名称需要多长时间？