DevOps 实战笔记
石雪峰
京东商城工程效率专家
37393 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
DevOps 实战笔记
15
15
1.0x
00:00/00:00
登录|注册

11 | 分支策略:让研发高效协作的关键要素

特性分支的原子性和完整性
对特性分支的命名规范要求很高
考验团队特性拆分的能力
分支成了特性天然的载体
分支开发相对比较独立,不会因为并行导致互相干扰
可能会导致两边提交不同步的情况
对团队协作的节奏要求很高
对主线分支的质量要求很高
发布分支一般以版本号命名,清晰易懂
只有一条主线分支,不需要在多条分支间切换
Facebook的分支策略演进案例
适用于追求持续交付的公司
缺点和挑战
优势
缺点和挑战
优势
适用于版本节奏驱动的软件项目
提出了一些思考题,鼓励读者参与讨论和分享
找到适合当前团队的分支策略是最重要的
分支策略是研发协作和发布模式的风向标
主干开发,主干发布
分支开发,主干发布
主干开发,分支发布
思考题
总结
介绍了三种分支策略
分支策略

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

你好,我是石雪峰。今天我们来聊聊分支策略。
在上一讲中,我反复强调过一个理念,那就是将一切纳入版本控制。其实,现代版本控制系统不仅可以记录版本和变更记录,还有一个非常重要的功能,那就是分支管理
现代软件开发讲究效率和质量,大多依赖于多团队间的协作来实现。对于一些大型软件来说,即便是百人团队规模的协作也没什么奇怪的。如果软件架构没有良好的拆分,很有可能出现几百人在一个代码仓库里面工作的情况。这时,分支管理就成了不可或缺的功能。
一方面,分支可以隔离不同开发人员的改动,给他们提供一个相对独立的空间,让他们能够完成自己的开发任务。另一方面,整个团队也需要根据软件的发布节奏来完成代码提交、审核、集成、测试等工作。
所以,如果说多人软件协作项目中有一个灵魂的话,我认为,这个灵魂就是分支策略。可以说,分支策略就是软件协作模式和发布模式的风向标。选择一种符合 DevOps 开发模式的分支策略,对于 DevOps 的实践落地也会大有帮助。
今天,我会给你拆解一些常见的分支策略,帮你了解这些策略的核心流程、优缺点,以及适用的场景和案例。

主干开发,分支发布

确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分支策略在现代软件开发中扮演着至关重要的角色。主干开发、分支发布是一种常见的分支策略,适用于版本节奏驱动的软件项目。在这种模式下,特性分支成为特性的天然载体,保护了主干分支的质量,同时也为以特性为粒度进行发布提供了可能性。然而,这种模式也面临着特性拆分能力、分支命名规范和特性分支的原子性和完整性等挑战。解决方法包括建立提交准入门禁、采用版本火车方式加快迭代速度、以及通过自动化手段扫描差异等。选择符合DevOps开发模式的分支策略对实践落地具有重要帮助。文章介绍了主干开发、主干发布的分支策略,并以Facebook的案例展示了其演进过程。最后,提出了主干开发结合特性分支的模式,并给出了执行过程中需要遵守的原则。总之,本文通过介绍不同的分支策略,为读者提供了对比和思考的机会,同时强调了选择适合团队的分支策略的重要性。

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

全部留言(16)

  • 最新
  • 精选
  • 桃子-夏勇杰
    代码冲突其实是团队协作的投射,经常小冲突是健康的表现[呲牙]怕就怕平时没冲突,关键时候炸个雷。

    作者回复: 哈哈,看来你也经历过关键时候炸雷,记得在某大公司做做手机项目的时候,就有一次UI层的应用依赖了谷歌的新版本基线,而Framework往下还是老版本的,原本以为不会出什么问题,合并就发现一些基础功能显示异常,结果临时让厂商发了一版新的基础代码,在合并的过程中出现了大量的冲突,在解决冲突的时候由于一小段代码被人为删掉了,结果发布之后在特定版本的手机上发生大量的闪退问题,于是又紧急修复新版本上线,可以说是相当狼狈的一次经历。

    2019-11-05
    11
  • 我来也
    有个疑问问下: “3. 每天向主干合并一次代码,如果特性分支存在超过 1 天,那么每天都要同步主干代码;” 这里是每天 a.把主干的代码合并到特性分支 b.把特性分支合并到主干分支 c.双向合并 选哪一个呢? 如果是b和c,那主干分支可能就不是随时可发布的了。 如果是a,可能最后合并回主干时,冲突会少些。

    作者回复: 你好,我也比较推荐a方法,实际上在特性没有开发完成之前,合并进主干也并没有什么实际意义,反而要引入特性开关等机制来保证这段特性没有启用,实际操作过程中特性分支定期rebase主干分支,这样既避免了双向合并,也让特性分支的历史足够清晰,推荐给你。

    2019-11-08
    3
    8
  • Robert小七
    金融行业很多都是采用多环境分支,例如存在sit,uat,prod分支,环境分支和主干分支长期并存,请问老师在这种情况下该采用怎样的分支策略?

    作者回复: 看来你也是金融行业的一员呀,的确我接触过的大多数金融公司都是采用你说的这种方式,基于环境的分支管理策略,我给他们的建议就是两点: 1. 不强制要求使用单一主线,但是要控制并行的版本分支,比如按照1个月1批次的发布模式,在这一月里只有一条版本分支,同时除了月末的集中上线之外,可以增加自身模块的上线频率,也就是1大多小的方式 2. 环境分支统一为发布分支,在一条分支上通过制品晋级的方式实现多环境的覆盖,也就是在测试环境验证通过后,按需部署到后续sit,uat等环境中,不再使用多环境分支来隔离,而是通过配置文件等方式来做到单一制品包加可变配置的方法

    2019-11-05
    2
    6
  • leslie
    大会时和老师的巧遇算是一种很好的补充:其实关于老师今天的东西,可能目前在不同的企业落实和情况不一样吧? 记得看到一个老师说过DevSecOPS最难的是踏实的落地:其实这体现了一个方面就是"坑"如何去避免吧。有些坑可能不是我们是否想去避免就能避免:记得现在有同行问版本控制经理的事情,其实这块现在已经是一个完整的产品了。其实这种趋势我个人感觉非常明显:过去的一些分支当真实启动了足够的作用之后都变成真实的产品,而真实懂软件的不会是Sell出身的产品经理,深处这行多年的IT人。 走出来参加大会:反思很多很多,其实对于不同企业的策略应当是不同的。不同的版本发布策略都经历过:小企业可能每周一次足够了,可是大了就不够了,其中人与人的沟通或者说协调折中去选择合适当下的策略就变成关键了。 举个很有趣的例子,为何数据工程师很多时候是开发和产品之间沟通的桥梁,大量的时间在做产品经理和项目经理直接的中间沟通桥梁,有时甚至是灭火器?

    作者回复: 能有这样的思考说明参加大会还是很走心的,说白了别人家的东西怎么为我所用,也是我一直思考的东西,因为你面临的场景和挑战都不相同,又怎么可能用一套解法呢?这些最基本的原则是项目实施中可参考的事情,就像你说的,选择合适的策略就是能力的考验了。 你应该是我第一个见过面的网友哈,可以常沟通哈。

    2019-11-05
    4
  • 陈斯佳
    老师,我有个关于分支的问题,就是我们公司的情况是每周至少一次小发布,一个月一次固定大发布,而且有五个以上的不同应用同时开发。我们的分支命名是以日期为格式。不同日期的分支会同时开发。生产环境自己单独一条分支。 我们现在的问题是,一个小发布或大发布上线,代码融入生产分支之后,需要反向同步到其他正在开发的分支,而且经常会有代码冲突。这个给运维和开发都增加了不小工作量。想问下,您遇到过这样的情况吗?有什么好的建议来降低这个工作量吗?

    作者回复: 你好,我的理解只要存在并行分支,就会有同步冲突的问题,除非这些分支在代码模块划分上就已经界定清楚了,比如购物车分支,订单分支,商品分支,各自有各自的代码路径甚至仓库,不会修改同一份代码,那么自然也就不会有冲突了。 单从你的描述中,我还是没有特别清楚你们的分支策略图,比如小发布和大发布都有独立分支吗,是顺序开发吗,比如一个小发布上了之后再拉出下一个小发布分支? 如果在开发过程中,并行分支是完全隔离的,只有归并到主分支之后才会同步到其他分支,这和持续集成的理念是有冲突的,之前在一家金融企业见过的就是你说这种方式,后来改成特性分支模式,小版本大版本都从主干拉出来发布,只有共享主干,及时合并,才有可能减少冲突量,有兴趣讨论的话,可以补充一些信息,我们一起看看哈。

    2019-11-07
    3
  • johnny
    老师,我有个问题。 在“主干开发结合特性分支的模式”分支策略中, 特性分支开发完成,代码已经集成到主干分支,主干分支并将特性分支发布后,发现特性分支上有bug要修复,是直接在特性分支上修复还是在主干分支上修复? 备注:我从文中提供的参考中学习到,特性分支并入主干,特性分支应该销毁,所以我认为特性分支的bug应该是在主干分支上修复。 期待老师的回答。

    作者回复: 你好,这里面有一个非常关键的点,就是特性是否已经发布上线了。如果特性还没有发布上线,那么特性分支自然还存在,就应该先在特性分支上修复,然后合并主线,这是为了保证特性分支上的独立性。如果说,特性已经发布上线了,那么再发现的问题就是一个新的缺陷或者需求了,可以理解为一个新的特性,所以需要重新拉出特性分支来,当然对于紧急情况,也可以Hotfix分支修复,再回归主线,这要看你们的发布模式,是向前升级,还是在线修复哈。

    2019-11-28
    2
  • 陈文涛
    个人认为分支开发,主干发布,最根本的还是要有成熟全面的自动化测试进行支撑,当然也包含老师提到的准入门禁等等,如果没有这些东西,那还是不要选择分支开发,主干发布了,最终的结果就是主干被玩坏。所以我们现在走的是分支开发、分支测试、分支发布、再并入主干,然后再从主干打出新的开发分支。

    作者回复: 是的,主干质量是永恒的话题,其实分支开发,分支发布也是类似的,只要有一个集成的主分支,那么提交质量不达标,就很容易导致团队阻塞。

    2019-11-22
  • pines
    我们这目前采用的是分支开发,主线发布。感觉确实不是很爽,找个机会改了

    作者回复: 期待你的实践分享哈!

    2019-11-05
  • Ios王子
    我们就是主干开发,主干发布
    2020-02-22
    4
  • 采用特性分支的方式,测试应该是测试特性分支打出来的应用,还是合并到开发分支后打出来的应用?
    2023-07-03归属地:广东
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部