持续交付 36 讲
王潇俊
携程系统研发部总监
39681 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
开篇词 (1讲)
结束语 (1讲)
持续交付 36 讲
15
15
1.0x
00:00/00:00
登录|注册

07 |  “两个披萨”团队的代码管理实际案例

解决A功能问题的办法
回顾和改进会议
清理过期分支
汇报和庆祝
修复问题并发布产品包
自动化测试结果
质量会议
解决延迟问题
集成测试和性能测试
代码review
测试环境配置和测试
开发人员处理分支冲突
测试工程师配置Smart Merge
开发人员建立特性分支
团队成员开始分配任务
团队成员介绍
“两个披萨”团队的概念
思考题
周五
周四
周三
周二
周一下午
背景
两个披萨团队的分支管理实践

该思维导图由 AI 生成,仅供参考

在亚马逊内部有所谓的“两个披萨”团队,指的是团队的人数不能多到两个披萨饼还不够吃的地步。也就是说,团队要小到让每个成员都能做出显著贡献,并且相互依赖,有共同目标,以及统一的成功标准,这样团队的工作效率才会高。
现在有很多互联网公司喜欢采用“两个匹萨”团队的模式,你可能很好奇,这些团队通常是如何实施代码管理的?
当前国内互联网公司通常采用特性分支开发的模式,我在第四篇文章《一切的源头,代码分支策略的选择》中,为你详细介绍了这种模式,下面我就以这种模式为例,为你解开困惑。
以迭代周期为一周的项目为例,我将按照从周一到周五的时间顺序,通过整个团队在每天的工作内容,跟你分享项目任务分配,分支创建、集成与分支合并、上线,包括分支删除的关系。你可以从中了解互联网公司研发团队日常代码管理的真实情况,体会团队为了提高研发效率,在代码管理上做出的创新与改进。

背景

周一上午 11:30,“复仇者” 团队的周会结束,会议室里陆续走出了 6 名工程师:
“钢铁侠”:5 年一线开发经验,现任“复仇者”项目经理及产品负责人;
“美国队长”:6 年开发经验,负责“复仇者”项目的技术架构,兼开发工作;
“绿巨人”:3 年开发经验,全栈开发;
“雷神”:3 年开发经验,全栈开发;
“蜘蛛侠”:1 年开发经验,负责几个成熟模块的维护;
“黑寡妇”:资深测试工程师,负责系统集成与测试。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

亚马逊内部的“两个披萨”团队以小团队高效工作为目标,采用特性分支开发模式进行代码管理。团队成员在周一分配任务后,通过GitLab创建特性分支并配置Smart Merge,实现自动合并和冲突检测。周二开发人员完成基本功能后,进行代码review和自测,同时测试工程师搭建测试环境并进行自动化测试。周三进行集成测试,发现延迟问题并通过Smart Merge排除引起问题的分支,最终修复Bug并决定周四上线。整个过程展现了团队高效协作、自动化合并和持续交付的特点。 在周四,“黑寡妇”进行了手工测试,发现并通知开发修复了界面文字描述的问题。产品包生成后,“黑寡妇”通过发布系统将产品包发布到线上,并及时给master打了tag,向项目组汇报。周五项目组清理过期分支,召开回顾和改进会议,讨论解决已有问题的方案。 这篇文章介绍了“两个披萨”团队的代码管理实践,展示了他们采用特性分支开发的具体活动,包括分支创建、集成和删除,以及周五的清理和改进会议。这些实践体现了团队的高效协作和持续交付能力,对读者的日常工作也具有借鉴意义。 思考题:如果A功能有问题不能上线,而B和C必须上线,可以考虑暂时移除A功能的代码,使得B和C能够独立上线。同时,需要及时通知相关人员,并在修复A功能后重新上线。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《持续交付 36 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(29)

  • 最新
  • 精选
  • 陈文涛
    老师我很好奇,大厂不写设计文档,不做设计评审,不做需求评审么,还是这场景忽略掉了。。。。

    作者回复: 当然要做啊,只是不限制形式,减少没有必要的paper works,比如以backlog,story等代替需求文档等,增加沟通,当然必要的设计说明也是要做的

    2018-10-31
    4
  • 军秋
    看B C是否有依赖A的功能,没有依赖撤回A,上线后两个,若有依赖,做个业务开关关闭A的功能保留BC依赖的功能,保证BC上线,A功能延期到下一个版本

    作者回复: 行得通,但是这类问题多了就会造成很多并无实际价值的业务开关,本身业务开关的管理也不是那么简单,因此此方法可以应急,但不推荐铺开使用

    2018-08-25
    2
    4
  • james
    老师,smart merge 的作用是不是, 先选定 N 个分支组成一个 group, 之后 group 中任何一个分支变更, 都合并到 group 中另外的几个分支中?

    作者回复: 应该说是整个group中的所有分支都会被合并到一个临时的,虚拟的分支里

    2018-08-25
    4
  • Linton
    smart_merge是需要Gitlab通过源码方式一并安装吗?

    作者回复: 是个gitlab service,不需要重新安装,但可能有版本要求,

    2019-10-23
    1
  • 柠檬水
    您好,看过你们在Github上的smart_merge工具了,但是文档不像是Gitlab的一个插件,安装过程也和Gitlab的插件安装不同,能指点一下方向吗?谢谢。

    作者回复: 可以提issue到项目,我们会跟进的:)

    2018-08-01
    1
  • Triton
    如果是BUG也需要创建分支吗?

    作者回复: 如果是hotfix,那也是需要独立建分支的

    2019-07-30
  • frankie
    有了 Smart Merge,任何一个分支的变更会自动触发合并----那这个跟主干开发似乎差不多吧?

    作者回复: 是的,但是却不会污染主干

    2018-11-13
  • Guti
    感觉不怎么专业啊,连pull request都不用?携程自己开发的smart啥没看出多大作用

    作者回复: pull request是github的功能,我们基于开源的gitlab处理的代码平台,所以使用的是merge request,两者还是有一定区别 至于smart merge插件,对于大型团队,并行开发多的就会看出它的价值了

    2018-07-30
  • Nick~毓
    多说一些 devops 持续交付 持续部署 持续集成 相关的理论 流程 标准 和实战经验吧
    2018-07-20
    15
  • 破晓
    回滚到提交abc前,重新上bc。
    2018-07-19
    10
收起评论
显示
设置
留言
29
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部