DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

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

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

主干开发,分支发布

取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

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

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

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

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

    2019-11-05
    1
    3
  • 我来也
    有个疑问问下:
    “3. 每天向主干合并一次代码,如果特性分支存在超过 1 天,那么每天都要同步主干代码;”

    这里是每天
    a.把主干的代码合并到特性分支
    b.把特性分支合并到主干分支
    c.双向合并
    选哪一个呢?

    如果是b和c,那主干分支可能就不是随时可发布的了。
    如果是a,可能最后合并回主干时,冲突会少些。

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

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

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

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

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

    2019-11-05
    1
  • 牧野静风
    我们基本几个人一个项目,貌似多分支开发,主分支开发都有
    2019-12-05
  • johnny
    老师,我有个问题。
    在“主干开发结合特性分支的模式”分支策略中,
    特性分支开发完成,代码已经集成到主干分支,主干分支并将特性分支发布后,发现特性分支上有bug要修复,是直接在特性分支上修复还是在主干分支上修复?

    备注:我从文中提供的参考中学习到,特性分支并入主干,特性分支应该销毁,所以我认为特性分支的bug应该是在主干分支上修复。

    期待老师的回答。

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

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

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

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

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

    2019-11-05
收起评论
9
返回
顶部