跨团队的持续集成: 几个基本矛盾

 

单个团队内部的持续集成已经是成熟的实践. 跨团队的集成则碰到了很多问题, 包括全部测试运行时间过长, 合并成本高等问题. 针对这些问题有一些对应的解决方案, 如合理的分支策略, 分层的集成等.

这里想讨论一下几个基本的矛盾, 和理想中的解决方案

 

1. 并行开发 与 集成 之间的矛盾

这是本质问题, 如果所有功能都是由单一开发者循序渐进的完成, 则集成并不是大问题. 由于团队内部的集成已经有大量成熟的实践, 因此前面的假设可以修改为"如果所有功能都是由同一团队循序渐进的完成, 则集成并不是大问题". 这就为我们指出了一条思路: 如果把需要集成的部分, 都分配给一个团队去完成, 则会大大降低集成的难度

传统的大规模开发中, 往往按照模块划分开发团队, 比如做UI的, 做网络通信的, 做数据库访问的, 做协议的, 等等, 分别是不同的团队. 而最终为了完成某个用户可见的功能, 需要协调多个团队并行开发, 然后联调, 也就是集成. 也就是说, 是特性需要集成. 如果我们按照特性来划分团队, 则跨团队的集成将转化为团队内部的集成. 而团队内部的集成已经有大量成熟的实践

关于特性团队和模块团队的全面比较, 请参见<<Choose Feature Teams over Component Teams for Agility >>

降低集成成本的第一原则就

阅读终点,创作起航,您可以撰写心得或摘录文章要点写篇博文。去创作
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

chelsea

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值