在持续集成中处理多个分支

Question

我一直在处理在我的公司扩展CI的问题,同时试图找出在CI和多个分支机构中采取哪种方法.stackoverflow,多个功能分支和持续集成有类似的问题.我已经开始了一个新的,因为我想进一步讨论并在问题中提供一些分析.

到目前为止,我发现我可以采取两种主要方法(或者其他一些方法).

• 每个分支的多组工作(在这里谈论Jenkins/Hudson)
  • 编写工具来管理额外的工作
    • 批量创建/修改/删除作业
    • 每个分支的每个作业的自定义设置(SCM URL,dep管理库复制)
    • 一些人用shell工具,ant脚本和Jenkins CLI解决这个问题的例子.看到:
      1. http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
      2. http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729. HTML
      3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
      4. 自动配置或创建hudson作业
  • 将导致CI群集上的负载增加
  • 开发人员的反馈周期变慢(如果基础设施无法处理新负载)
• 每2个分支的多组作业(开发和稳定)
  • 手动管理两个集合(如果您更改作业的conf,请确保在另一个分支中更改)
    • PITA但至少要管理这么少
  • 其他额外的分支在推送到dev之前不会得到完整的测试套件
  • 不满意的开发者.为什么开发人员应该关心CI扩展问题.他有一个简单的请求,当我分支时,我想测试我的代码.简单.

所以,如果我想为他们自己的自定义分支提供开发人员,我需要Jenkins的特殊工具(API或shellcripts或其他什么？)并处理扩展.或者我可以告诉他们更频繁地合并到DEV并且在自定义分支上没有CI.您会选择哪一个或有其他选择？

Answer 1

当您谈到扩展CI时,您真正在谈论扩展CI服务器的使用以处理您的所有功能分支以及主线.最初,这看起来是一种很好的方法,因为分支中的开发人员可以获得CI作业所包含的自动化测试的所有优势.但是,您在管理CI服务器作业时遇到了问题(就像您已发现的那样),更重要的是,您并没有真正使用CI.是的,您正在使用CI服务器,但您没有持续集成所有开发人员的代码.

执行实际CI意味着您的所有开发人员都定期向主线提交.很容易说,但困难的部分是在不破坏您的应用程序的情况下这样做.我强烈建议您查看持续交付,尤其是第13章:管理组件和依赖关系中的" 保持应用程序可释放"部分.要点是:

• 隐藏新功能直到完成(AKA 功能切换).
• 将所有更改逐步进行为一系列小的更改,每个更改都是可释放的.
• 使用逐个分支来对代码库进行大规模更改.
• 使用组件将应用程序中以不同速率更改的部分分离.

它们非常自我解释,除了抽象分支.这只是一个奇特的术语:

1. 在需要更改的系统部分上创建抽象.
2. 重构系统的其余部分以使用抽象层.
3. 创建一个新实现,该实现在完成之前不是生产代码路径的一部分.
4. 更新您的抽象层以委派给您的新实现.
5. 删除旧的实现.
6. 如果不再合适,则删除抽象层.

第14章:高级版本控制中的分支,流和持续集成部分的以下段落总结了影响.

增量方法当然需要更多的纪律和关注 - 实际上更多的创造力 - 而不是创建一个分支和潜水重新构建和开发新功能.但它可以显着降低您的更改破坏应用程序的风险,并将为您和您的团队节省大量时间合并,修复破坏并使您的应用程序进入可部署状态.

放弃功能分支需要相当大的思维转变,你总会遇到阻力.根据我的经验,这种阻力是基于开发人员不能安全地将代码提交给主线,这是一个合理的问题.这反过来通常源于缺乏对上述技术的知识,信心或经验,并且可能对您的自动化测试缺乏信心.前者可以通过培训和开发人员支持来解决.后者是一个难以处理的问题,但是分支并没有提供任何额外的真正安全性,它只是推迟了问题,直到开发人员对他们的代码充满信心.