策动&编辑｜雅纯
上一讲，咱们具体介绍了4种常见的分支模式及其优劣比照。本文咱们将依据不同的团队场景，剖析如何抉择适宜团队的研发模式。
研发模式抉择看什么
研发模式的抉择与产品状态、公布形式、团队规模、合作成熟度密切相关。比方团队规模很小，合作成熟度很高，就间接用骨干开发。相似于Web服务端的开发，能够做到继续部署，能够抉择GitHub—Flow，或者是TBD。
如果你的团队规模比拟大，须要开发的时候做相应的隔离，再看合作的成熟度。如果个别就用GitHub—Flow，成熟度很高就用TBD。
另外，有一些研发场景有固定的公布窗口，它是按版本的形式去公布，咱们倡议有相应的release分支去做隔离。理论过程中咱们应该尽可能地依据本人理论的产品和团队状况，来去制订适合的分支规定。
举一个例子，这张图的上半局部是需要价值流。能够看到他们开发的时候是一个需要一个需要地做，做完一个需要再做另外一个。因而能够看出这是一种继续交付需要的形式，针对一个需要会做相应的代码变更。
与之相应的分支模式为GitHub—Flow。
在做个性开发的时候，只有做个性之间的隔离，然而能够做到继续公布，所以间接在Master上公布就好，因为是在Master下来公布，所以不会同时有两个公布存在。
能够看到分支模式和公布流水线之间是强相干的。公布流水线会基于不同的分支来去做相应地事件。比方个性分支发生变化后，针对个性分支做相应的集成和验证，通过后再合到Master下来做集成，实现集成后做相应的SIT（零碎级别的验证），而后再做部署。因而分支模式和公布流水线之间是强相干的。
这是继续公布的形式。
版本制公布模式常见于客户端的公布。例如iOS或安卓，因为有肯定的公布节奏。和下面的继续公布模式相比多了一个release分支，用来做版本公布用。从整体来看分支模式比较简单。不倡议用Git—Flow，能够对其适当进行裁剪。
研发模式的目标是缩小代码合作当中的抵触，缩小期待。代码之间的合作抵触有两种，一是开发过程中的抵触和隔离，另一个是公布过程中的隔离，所以组合形式无非是：分支开发和骨干公布、分支开发和分支公布、或是骨干开发和分支公布等几种。
这个例子初看和Git—Flow一样，然而绝对于Git—Flow，它有两个变动。首先，它没有release分支，它的公布体现为在骨干上打Tag。第二，它的hotfix不合回骨干，而是间接在hotfix上打Tag进行公布。这样它就少了release分支，少了hotfix和master之间的同步。
整个分支模式有这样一个特点，它有四种分支：feature分支、develop分支、master分支和hotfix分支，其中develop和master是长期分支，feature和hotfix是短期分支。开始开发的时候会拉一个feature分支，合并实现后沦亡掉，如果是热修复，会拉一个hotfix分支，hotfix分支永远是从tag上创立的，之后创立tag，分支沦亡。
所以长期分支就两个，大部分的状况下hotfix就是feature分支，整个流程比Git—flow简化很多。
分支模式实际案例剖析
分支模式是和产品的状态和团队是强相干的，以下是几个实际案例。
1、P2P直播CDN产品
第一个案例是P2P直播CDN产品，右边是它的架构图，分为一个客户端和一个服务端。客户端是有多端的，比方手机、路由器、机顶盒等，每一种端的公布模式是不一样的。终端，客户端和服务端之间有两条通信链路，一条是视频数据的链路，另外一条是控制数据的链路。
服务端包含了三局部，管制面、用户面，和数据、经营、监控等服务。每一块都蕴含多个具体的利用。团队成员物理上在一起，合作严密，工程能力还能够，有单元测试和性能自动化保障，基本上能够做到比拟快的测试反馈。
它有两种利用：一个是服务端利用。个别golang、C++都是通过源码级构建依赖，运行时依赖配置核心，共30个左右利用，一次公布一个利用，每个利用是独立公布，所以不存在公布的依赖性和编排问题。
另外一个是客户端，一个代码多端构建，无运行依赖，有的能够热更新，有的须要通过利用市场公布，比如说iOS，所以公布频率不太一样，会导致长期有多个版本存在。那么，怎么针对服务端和客户端去做研发模式的设计？
首先看服务端，服务端是一个看上去比TBD还简略的模式，因为人很少，服务拆得足够小，简直每个服务同时只有1—2集体在批改。这样的状况下就没必要再用release分支，间接在骨干上开发。基本上一个服务一个库，而且这个服务拆得粒度很小，均匀一个人大略是3、4个利用，这个服务是很小的。
这样的状况下，它会有一些本人的纪律，比方因为要保障多端和客户端多版本，代码须要保障向前兼容，同时代码是间接Push在Master分支上的，不存在合并等问题。在Master上一旦代码提交会有对应的测试，如果测试失败，提交者须要在一小时内修复。在Master上创立Tag即会视为一次公布。
如果呈现问题，在最新代码上修复，永远公布最新的版本。这就是服务端的流水线，所以如果有相似的团队倡议能够尝试一下，基本上来说如果做好纪律，能够做到很高效地公布。
客户端基本上就是TBD的模式。平时还是骨干开发，代码在骨干上集成，然而要公布的时候会拉一个release分支，因为客户端的公布和降级比拟艰难，须要做足够多的公布前验证，这个状况下就须要release分支去爱护。同时因为它会同时存在多个版本，所以须要在release分支上做bugfix。
然而，release分支还是要放弃沉闷数尽量地少，所以个别只关注最新的沉闷的release分支。这样TBD是一个十分适合的模式，针对公布它会做隔离，另外，因为一个版本须要放弃肯定工夫的保护，所以须要一个绝对长期的release分支。
2、根底网络产品
它是在软件层面做的虚拟化网络产品，很多内部做一些底层产品的公司会遇到这样相似的产品。整个产品研发50人左右，分为5个团队，每个团队大略10集体。团队间合作需要很高，个别都是一起公布、一起集成，但开发的时候是很多人一起开发的。
整个团队工程能力中等，有单元测试然而没有其余测试的爱护，前面的测试次要是靠具体的环境去测，开发的语言是C+和C++为主，部署到物理机或者虚拟机上。利用是一份代码，多端构建，须要应答多种的硬件和操作系统，底层依赖Hypervisor和硬件。部署时可能须要停机，因为网络问题不是总能做到热更新，一次部署一个利用，公布程序有要求。
如果有多个利用，利用间的公布有编排程序，它的公布周期很长，通常几个月公布一次，同时会存在两个都在公布的版本，比方一个版本公布了80%，另外一个版本公布了10%。
这个产品的release分支会更长，它的版本须要固定下来，要有明确的Tag。所以Master不能间接提交，永远指向最初一个已公布的版本，然而整个开发其实是拉release去做，这个release可能会比拟久。
在这边做完当前，在release做残缺的测试和评审而后公布，实现后合进Master。这个相似于我的项目制，一个release相当于一个我的项目，从Master上创立进去当前，所有的开发和公布的工作都在这个release分支上，这个release分支就相当于我的项目的版本。公布完后release分支进入维护阶段。Master在这里是作为一个稳固基线来治理的。
3、金融平安产品
这个产品一份代码提供两种交付状态，包含SaaS和私有化交付状态。整个利用架构比较简单，蕴含一些后盾服务和API入口，以及一个治理和配置用的控制台。后盾服务外面API会调很多其余的服务，比方设施指纹、指标计算、数据服务等。
这是典型的大数据场景，包含很多人工智能的产品都是相似的架构。整个团队在150人左右，它的特点是前端、算法、后端、测试都有专门的职能团队，然而没有运维。
团队之间通常须要合作能力实现一个要求，一般来说不会有一个需要落在某一个团队，工程能力个别，没有单元测试和自动化功能测试的守护，基本上是靠后续的人工测试来去保证质量。
整个技术栈是以Java为主，K8s部署形式。另一个特点是二方包依赖较多，snapshot和release版本都有。运行时利用间有较强依赖，比方在API依赖了设施指纹，API依赖了指标计算，相似这样的依赖其实很多。
整个利用数大略是20个，一个利用很多人合作，一次公布往往是一组利用或者是一个利用，SaaS版本落后私有化版本较多。
它和Git—Flow有点相似，区别是没有Develop分支，release分支用来做了长期的集成分支，Master是公布分支，永远指向最新可公布版本。
作为私有化产品，有固定的版本节奏，个别一个月公布一个版本，于是每个月会拉一个release分支来做这个月的Feature分支的集成。集成完当前会合回Master去做公布，公布完打一个Tag。
所以在这里的release分支相当于一个迭代分支。整个测试是比拟长的周期，同时也要保护多个版本，因而会有多个并行的release分支存在。
通过这几个例子能够发现，咱们须要依据团队和产品的特色来确定它的分支模式。在这些分支模式外面，咱们都尽可能地缩小分支，让分支的保护成本低一点，因为每多一个分支意味着多一份保护老本。
除此以外，还有一些其余的场景，比方集成过程中，集成进去当前发现集成分支呈现问题，须要把相应地代码摘出来。很多的Feature分支合在一起，合并进去当前想再摘出来就很难。这种状况其实也能够用分支，比方长期的集成分支解决。阿里外部的研发工具Aone，有一个分支模式叫Aoneflow，就能够解决相应的问题。
很多时候分支是能够很灵便地去应用的，然而灵便应用也会给程序员带来特地多了解和保护老本。咱们的倡议是分支越简略越好，另外尽可能地缩小程序员的关注度，只关注在本人开发的分支上就好。这里给出几点倡议：
- 单骨干：一个代码仓库应该保障有且仅有一个骨干分支。像Gitflow外面Develop和Master就比拟蛊惑。
- 起码长期分支：防止抵触的前提下，尽量减少长期分支的数量
- Promotion（升级）：代码的提交应该是逐级合并，如Feature–Develop-Master，是逐渐地Promotion的过程。
- 公布不可变：公布的版本是不可变且可回溯的，能够依据Commit来追溯到你最早的源头。
- 自动化事件触发：分支的继续集成过程应该是自动化的，且通过代码提交事件或制品变更事件主动触发。
总结
- 团队研发实质上是一个异步的、提早合作的过程，随着产品复杂度和团队复杂度的减少，合作老本疾速回升。
- 研发模式的实质是为高效交付需要，研发团队围绕代码库的一系列行为束缚。
- 通过分支进行隔离，防止抵触;通过小批量频繁提交，缩小期待。
- 管制分支须要思考最大化生产力及最小化危险。
- 分支的抉择须要综合团队规模、合作成熟度、产品交付状态几个因素。
下一讲，咱们将进入可信公布篇，敬请期待。
点击下方链接，收费体验云效流水线Flow。
https://www.aliyun.com/produc...