在持续集成中处理多个分支
我一直在处理我公司的CI扩展问题，同时试图弄清楚在CI和多个分支机构中采用哪种方法。在stackoverflow，多个功能分支和持续集成方面存在类似的问题。我开始了新的话题，因为我想进行更多的讨论并对该问题进行一些分析。 到目前为止，我发现我可以采用2种主要方法（或者可能采取其他一些方法？）。 每个分支多套工作（在这里谈论詹金斯/哈德森） 编写工具来管理额外的工作 批量创建/修改/删除作业 每个分支的每个作业的自定义设置（SCM url，dep管理存储库重复项） 人们使用shell工具，ant脚本和Jenkins CLI解决此问题的一些示例。看到： http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-on-on-each-one-without-duplicatin-td954729。 html http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html 自动配置或创建hudson作业 将在您的CI群集上造成更多负载 开发人员的反馈周期变慢（如果基础架构无法处理新的负载） 每2个分支有多套作业（开发和稳定版） 手动管理这两个集合（如果您更改作业的配置，那么请确保在另一个分支中进行更改） PITA，但至少很少要管理 其他多余的分支机构在推向开发人员之前不会获得完整的测试套件 开发者不满意。开发人员为什么要关心CI扩展问题。他有一个简单的请求，当我分支时，我想测试我的代码。简单。 因此，如果我想为开发人员提供用于其自定义分支的CI，则我需要Jenkins的特殊工具（API或Shellscript或其他东西？）并进行缩放。或者，我可以告诉他们更多地合并到DEV并在定制分支上不使用CI地生活。您会选择哪一个？或者还有其他选择？