持续交付36讲
王潇俊
携程系统研发部总监
立即订阅
7125 人已学习
课程目录
已完结 41 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 量身定制你的持续交付体系
免费
基本概念 (3讲)
01 | 持续交付到底有什么价值?
02 | 影响持续交付的因素有哪些?
03 | 持续交付和DevOps是一对好基友
配置管理 (4讲)
04 | 一切的源头,代码分支策略的选择
05 | 手把手教你依赖管理
06 | 代码回滚,你真的理解吗?
07 |  “两个披萨”团队的代码管理实际案例
环境管理 (6讲)
08 | 测试环境要多少?从现实需求说起
09 | 测试环境要多少?从成本与效率说起
10 | 让环境自己说话,论环境自描述的重要性
11 | “配置”是把双刃剑,带你了解各种配置方法
12 | 极限挑战,如何做到分钟级搭建环境?
13 | 容器技术真的是环境管理的救星吗?
构建集成 (5讲)
14 | 如何做到构建的提速,再提速!
15 | 构建检测,无规矩不成方圆
16 | 构建资源的弹性伸缩
17 | 容器镜像构建的那些事儿
18 | 如何做好容器镜像的个性化及合规检查?
发布及监控 (6讲)
19 | 发布是持续交付的最后一公里
20 | Immutable!任何变更都需要发布
21 | 发布系统一定要注意用户体验
22 | 发布系统的核心架构和功能设计
23 | 业务及系统架构对发布的影响
24 | 如何利用监控保障发布质量?
测试管理 (3讲)
25 | 代码静态检查实践
26 | 越来越重要的破坏性测试
27 | 利用Mock与回放技术助力自动化回归
持续交付平台化 (3讲)
28 | 持续交付为什么要平台化设计?
29 | 计算资源也是交付的内容
30 | 持续交付中有哪些宝贵数据?
持续交付移动App (3讲)
31 | 了解移动App的持续交付生命周期
32 | 细谈移动APP的交付流水线(pipeline)
33 | 进阶,如何进一步提升移动APP的交付效率?
实践案例 (4讲)
34 | 快速构建持续交付系统(一):需求分析
35 | 快速构建持续交付系统(二):GitLab 解决代码管理问题
36 | 快速构建持续交付系统(三):Jenkins 解决集成打包问题
37 | 快速构建持续交付系统(四):Ansible 解决自动部署问题
特别放送 (2讲)
持续交付专栏特别放送 | 答疑解惑
持续交付专栏特别放送 | 高效学习指南
结束语 (1讲)
结束语 | 越痛苦的事,越要经常做
持续交付36讲
登录|注册

04 | 一切的源头,代码分支策略的选择

王潇俊 2018-07-12
记得大概是一年前吧,我与好友老吴喝茶聊天时,讨论到:高效的持续交付体系,必定需要一个合适的代码分支策略。
我告诉老吴:“采用不同的代码分支策略,意味着实施不同的代码集成与上线流程,这会影响整个研发团队每日的协作方式,因此研发团队通常会很认真地选择自己的策略。
老吴是一名有多年开发经验的资深架构师,当时正好要接手一个框架团队,从个人贡献者向团队管理者转型。他个人对代码管理工具可谓熟之又熟,甚至连“老古董”的 CVS 都可以跟你聊半天。但他在为团队制定代码分支管理策略时,还是慎之又慎,足见其重要性。
最后我们发现,要确定选用哪种代码分支管理策略,需要先假设几个问题,这几个问题有了答案,也就代表你找到了适合的方向。
你需要思考的几个问题如下:
Google 和 Facebook 这两个互联网大咖都在用主干开发(Trunk Based Development,简称 TBD),我们是不是也参照它俩,采用主干开发分支策略?
用 Google 搜索一下,会发现有个排名很靠前的分支策略,叫“A successful Git branching model”(简称 Git Flow),它真的好用吗?团队可以直接套用吗?
GitHub 和 GitLab 这两个当下最流行的代码管理平台,各自推出了 GitHub Flow 和 GitLab Flow,它们有什么区别?适合我使用吗?
像阿里、携程和美团点评这样国内知名的互联网公司,都在用什么样的分支策略?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《持续交付36讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(31)

  • 康美之心 淇水之情
    微服务架构下,比较适合主干开发,一个微服务(含1-4个API)根据复杂性和规模通常由1-3的开发进行开发(含单元测试的开发),1位测试进行API自动化测试开发,单元测试和API测试都集成到Pipeline上,一旦变动代码提交到master上后,就自动启动Pipeline上的build,在build这里会自动完成覆盖率100%的单元测试,单元测试通过,自动触发FVT deployment,部署成功后,自动触发FVT API自动化测试,FVT测试通过后;自动打出上线的tag号,并把这个tag号的部署到UAT,UAT部署成功后,自动触发UAT的API自动化测试,测试通过后,这个UAT的tag的就可以部署上线了。

    作者回复: 讲的好,主干开发除了cherry pick以外,都简单直接

    2018-07-14
    13
  • 禾子先生
    对于开源项目不适合用主干开发。我的理解是更应该采用gitlab flow,为了保证功能稳定性,在贡献者的能力参差不齐和对整体架构和功能不一定完全了解情况下,修改的代码可能会引起其他问题。通过带版本分支的方式发布,稳定的推进和测试新代码的影响。
    2018-07-13
    6
  • 禾子先生
    对于第二个问题,我的思考是使用github flow,虽然追求效率,但必须保证线上版本是一个稳定。大家都在开发分支中进行开发,快速测试和迭代,合并到master时冲突也少。也考虑过使用主干开发,不过但从稳定角度来说,还是选择了前者

    作者回复: 很棒

    2018-07-13
    3
  • bullboying
    在自动化测试还没怎么做到位的情况下,为了控制合并到master的都是经过测试的代码,我们增加了一个SIT分支。每次有新特性需要开发时,从master分支check out一个特性分支进行开发,可能涉及到多人协同开发。自测完成后先发起merge request到SIT分支,如果有冲突则不允许merge,以实现不同特性分支间的隔离。如果没冲突且有集成测试人员空闲,则完成merge并安排测试,测试通过后由masters再发起merge request将特性分支合并到master。因为之前控制了冲突,所以第二次合并理论上是没有冲突的。现在纠结的几个问题,一是想要限制不能从SIT分支pull,否则就达不到多个特性分支隔离的效果,全靠开发人员自觉;二是因为隔离冲突是为了限制在制品,但导致master和SIT分支上的代码其实是不同的,是否需要测试两次?

    作者回复: 您提到利用SIT分支来保证合并到master的都是经过测试,我们强烈建议使用 SmartMerge(本专栏第7讲) 来代替SIT,可以更及时地发现代码集成冲突的问题,其次可以更便捷地决策出用于上线的最大集合。

    提到的第一个困惑,我们采用SmartMerge后,对应会有SmartMerge的分支,第一个问题演变为“怎么限制开发不要从SmartMerge的分支创建新分支,而只能从master分支创建新分支?”我认为这个演变过来的问题非常好。可以从两个方面着手来规范。
    1)如果在gitlab UI上创建分支的话,我们可以很容易地限制只能从master创建新分支。
    2)另一方面我们不打算限制git客户端的行为,仅当git客户端向gitlab服务端push新分支的时候做相应的检查。为了判断新分支是否从master拉取且尚未和其他分支做merge,只需查看该分支和master的merge-base的commit之间,是否存在merge的commit即可,如果有,则不允许push。

    如果没有采用SmartMerge的方式,其实方法本质是相同的。如果短期内还是只能通过SIT分支的话,做法和SmartMerge的方式是一样的。
    口诀为:在服务端直接控制新分支的创建,且拒绝客户端push不规范的新分支。

    第二个困惑,假设你们尚未使用SmartMerge的方式,可以通过在你们的开发流程中额外增加一个活动来搞定。用于集成的SIT分支在编译打包前,务必和master做merge,打包测试后如果没问题的话,SIT和master分支做fast forward的检查,如果是fast forward,那么SIT merge到master分支产生的commit,内容和SIT 的HEAD是相同的,也就无需再一次进行测试了。如果你们master分支的变更只能来自SIT分支,那么这个fast forward是很容易得到保证的。

    2018-07-18
    2
  • 纳米
    您好 我是一个非开发的人员。弱弱问下,最后表里总结的生产分支 环境分支中,开发人员自身是check out哪个分支代码出来开发 又是往哪个分支集成呢。能否在这两个分支上帮细化下。非常感谢。

    思考题2 我理解 既然人很少 迭代周期也较为宽松 可能这一周大部分人都工作在一个功能或者版本上 是不主干开发反而也可以。github flow应该肯定是ok的。

    作者回复: 特性分支模式下,都是从production拉取的开发分支,然后合并到master,master做持续集成,为了不影响持续集成,所以有了从master拉出来的环境分支进行部署

    要考虑团队人员的能力,如果新人较多,就使用特性分支,反之使用主干开发,github flow的pull request其实也是特性分支

    2018-07-12
    2
  • 有道测试组
    选用什么样的开发方式,也有一定是基于历史遗留原因或者大家的编程习惯~
    开源软件不适合主干开发是说,我们会假设有若干贡献者,并且贡献者的水平参差不齐,会带来一粒老鼠屎,坏了一锅粥的问题。 但如果我们的pr 提交到master分支,会经过完善的自动化测试(包括各种配置,各种机型,我们将要做的所有测试), 测试通过才让合入。这样其实主干开发流程简洁,能加快开发效率。
    如果测试没那么自动化,可能需要先合入其他分支, 再通过线下完整的各方面校验通过,方能合入。
    目前像tf ,paddlepaddle等深度学习框架大多基于主干开发,分支发布。
    不管是主干开发分支发布,还是分支开发主干分布,主要是期望能全面保证质量后再发布, 并且发布后的代码能较方便的集成到版本库。中间建立多少层分支,一般决定于代码库贡献者的规模。
    2018-12-26
    1
  • 大M
    如果有不同环境呢,比如灰度环境,这样情况下我觉得是gitflow 比较合适。
    2018-07-17
    1
  • 董永刚
    分支类型中,带生产分支,带发布分支,带产品分支的分别是什么样的场景呢?

    作者回复: gitlab几个flow,除了用于集成的master分支外,额外还配置了其他用于测试或上生产的分支。

    拿带生产的分支来说,如果公司约定每周四才能发布到生产,而团队于周二在master上就集成好了V3.6版本,为了不影响后面的集成,master分支需要先merge到PRODUCTION分支,周四上线只需取PRODUCTION分支即可。

    当然,gitlab flow也只是提供一个解决方案而已,只要能在发布窗口时正确快捷地找到用于发布的commit,同时又不影响集成即可。

    至于提供带环境分支的,就是用分支模型来规约发布流程,保证用于上线的代码经过层层测试。做法就是约好了只能用PRODUCTION分支上线。比如通过PRE-PRODUCTION环境测试后,才能把该环境对应的分支合入到PRODUCTION分支。

    2018-07-17
    1
  • 小胖胖
    gogs被gitlab 应该选择哪个?有什么区别吗

    作者回复: 主要还是看你能hold住哪个,比如我个人属于rubyist,所以用ruby写的gitlab肯定就是我的首选了,如果你比较偏爱或擅长go,那就gogs了。

    相对来说我个人觉得gogs比较轻量化,有好处有坏处,比如你要大量二次开发,gitlab service形式就比较友好,而且最近也开源了HA方案

    2018-07-13
    1
  • 徐卫
    你好,问下。老师帮我看下理解对不对。主干开发是否只有一个分支,开发的代码提交到这个分支,发布也是用此分支。文中讲到的特性切换怎么做的? 我个人理解是在那个发布的版本上打标签,特性切换是从tag上拉出一份代码部署?

    作者回复: 主干开发也可以有多个分支,除了master,其他是发布分支,master是用来持续集成的,也就是大家只往master push代码

    特性切换不是分支,是代码或框架实现的功能,就理解为功能开关好了,也就是说有些代码即使上线了,也能通过开关保证它不工作

    2018-07-12
    1
  • 初七之月亮
    带环境发布分支方法的多数适用场景是啥呢?是不是有多少套环境就多少套分支啊?

    作者回复: 比如有些环境是独立与其他服务联调用的,为了保证master的持续集成,而又不至于污染这个联调环境,就需要一个独立分支了

    2018-07-12
    1
  • 云学
    到底用哪种分支策略和团队的业务分工有关,如果修改的代码交织严重,肯定是主干,如果不严重,可以主干可以分支
    2018-07-12
    1
  • 小胡子
    我们团队主干和开发两个分支并过来并过去,我该怎么解释这是种什么不好的方式呢。。。

    作者回复: 持续交付要求至少有一条分支随时能够进行发布,只要遵循这个原则,仅2条分支并无大碍

    2018-07-12
    1
  • 白天不懂爷的黑
    老师,您好,最近公司想用gitlab做配置中心,请问贵公司gitlab的高可用是怎么做的呢?谢谢

    作者回复: 最新版本应该给了和GitHub类似的解决方案,我们是对gitlab做了分片,每个分片是一个仓库,在集群之前增加了基于nodejs ssh2修改的proxy,仓库做简单的定时备份

    2018-07-12
    1
  • Geek_c991f2
    很早就知道你有这个文章,但是当时没太能看懂,今天回头来看.但是还是想评论下,感觉文章中说到的git flow和有点像另外3中gitlab flow的三种综合,希望老师回复下
    2019-08-08
  • 飞翔
    1 主要是提交质量不可控
    2 都能用,看团队需求

    分支的主要作用应该是隔离变化,带来的问题就是增加分支维护成本,对于一般团队来讲,都应该使用特性分支,只不过要注意减少维护特性分支的数量,有必要的增加分支

    以前只留意了git flow ,没留意其他模式,惭愧。
    2019-07-26
  • 春之绿野
    因为在开源软件上,个人开发的话每个人的质量无法保证,所以不能用主干开发。第二种情况用主干开发,因为人数少,特性分支的话迭代周期太长
    2019-06-04
  • 飞机翅膀上
    老师好,我们现在一个项目具有很多功能,还没有做微服务,甚至soa还没有做,产品在迅速迭代,目前一个master分支,一个test,和十几个特性分支,特性分支需要合并到test测试通过才可以将特性分支合到master发布
    由于特性分支太多导致合到test分支经常有冲突,甚至编译不通过。所以每天都要拉取master分支到特性分支做合并,尽管如此,还是会有冲突
    看了老师的课程,觉得有必要给每一个特性分支做测试环境,然而没有那么多的服务器,这点使用docker可以解决,至少做测试不需要合代码了,但这会导致最后特性分支测试通过合master时也会产生大量冲突
    在这样的一个场景下,该给哪些分支做持续集成呢?从而提高项目整体交付效率?
    我想过引入一个预发布分支,首先从master checkout下来,特性分支测试通过合到预发布分支,给预发布分支做持续集成,及时反馈预发布分支的健康状况
    非常希望老师能够给点建议,感激不尽!
    2019-05-01
  • llgeek
    有两个疑问请老师帮忙解答
    如果采用GitHub flow,一个长期的feature分支,需要如何跟master同步?
    feature分支提交pr后,测试完成,在分支发布或者合并到master在主干发布,如何评析优劣?
    谢谢老师
    2019-03-22
  • 木有昵称
    我们公司项目多,根据项目大小程度,基本上特别小的项目一个人开发直接就一个master分支;普通的项目是一个master分支加一个develop分支,多个开发人员使用develop分支进行开发,自行提交解决冲突,测试环境随时使用develop分支发布上线,生产线需要上线时由开发负责人专人负责合并到master上进行发布。
    2019-03-02
收起评论
31
返回
顶部