开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：为什么团队规模越大，发布反而慢了】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13512
为什么团队规模越大，发布反而慢了
内容介绍：
一、示例列举
二、并不是团队规模越大，研发的效率越高
三、场景示例
四、研发模式
一、示例列举
假如经营一个小镇，小镇需要协调各种资源，比如有一个很有意思的资源，火车要去运货，给火车装货，但火车装货，又去做生产，所以不同的产品的生产的进度、时间又不一样，需要去协调各种资源和各种时间，所以会发现，当成就越来越大的时候，火车经常招不满，等半天还发布了。
所以当时就觉得今天讲要讲的故事非常的贴近，城镇越大，越发现火车发不出去了，发火车想发火都发不出去了，这里其实和现实当中确实是很贴切，然后领域里觉得和之前接触到的一家企业，特别像这家企业是怎么样呢？
就是规模一开始的时候，刚创业的时候才八个人，那时每个月都可以发一两个版本出去，然后客户基本上都可以用到，做医院的系统的。医院的信息管理系统，觉得还很不错，而且发展特别快，后来整个团队的规模一下子到了80人，翻了十倍，半年都没有发一个版本，实施团队都没脸见客户。
因为客户说半年前提的需求，怎么还没有搬出来，所以这时发现了一个悖论，就是以为团队规模越大，研发效率就会越高，就可以做越来越多的东西，但是发现团队规模大到一定程度的时候，整个研发效率其实是会往下降。
二、并不是团队规模越大，研发的效率越高
如图的斜率下降的非常快，，这里其实带来一个很深的一个思考。为什么团队规模越来越大，发布反而会越来越慢？
到后来可能半年都发不出去一个版本。说明一个很严重的问题是站在很多团队发现很多人，人多了之后，协作会越来越慢，协作的成本也会越来越高，但是站在今天在讲工程的这一块角度不谈项目管理，更多是站在工程师的角度，每天面对代码，面对要去发布，面对要去开发新的需求这样的一些场景，发现团队的研发模式人越多会有问题，为什么冲突越多，等待越多。
比如冲突，这里指的冲突指的是在代码集成发布过程当中冲突，等待也是在集成过程当中比开发过程中的一些等待，对开发过程当中但彼此的一些。可以看一下两个具体的一个场景。
三、场景示例
看第一个场景，假设有两个程序员，A和B，都在一起工作，a一开始每次提交都是好的，把工作逐渐的提高到分值上去了，这时B提交了一个版本，然后版本导致分支一挂然后这时 a 就提交不了，因为交了也会挂，所以就必须等待并修复问题才能提交，这样的话 A 的提交就跟 B 的工作产生了一个冲突。第二种情况是什么呢？就是两个人在同时去干活会产生冲突，那拉开来，每人拉一个公司，a先进去核定主干晚了一点，结果发现喝不进去了，为什么呢？因为记性不一样，这时，就有代码冲突了，就先得把冲突解决了，才能合进去。所以这是两种非常常见的，很多人应该经常都会遇到这样的一种冲突的一个例子，代码上的冲突的一个例子。本质是什么呢？
其实来以时间轴的维度，来看一下其实假设现在有三个人，每个人这里一个点再做了一个任务，比如 a 一直在干自己的事情，每完成一个事情，开始做下一个事情，结果做完第三个事情的时候，觉得需要找 B 去联调一下就告给 B 发了个 ping，有时间聊一下吗？发一个东西，但是B有自己的节奏，在忙自己的任务，这时并没有马上去响应a的一个请求。发现，有一个任务，可以体测了，那就告诉C说可以提测了，所以拿过来检查有问题，马上回复就 pong 一下，但是这时并在干忙另外一个任务，所以就没有响应，C 又发现怎么没响应呢？在回忆这时B看到了，但是先处理了a的事情，所以 pong pong 回复了一个泡沫的消息，所以就发现，是程序员和程序员，测试人员和开发人员之间，在整个的开发协作中，其实是一个异步的延时写作的过程，并不会给一个请求，马上回复马上去协作，其实往往会有自己的一个步调，有自己的任务在做，然后可能会延迟告诉你，所以会发现当产品一复杂，比如产品上协作人一多，或者团队复杂，团队上人一多之后，协作成本其实就快速往上升。倒是想到了钉钉，钉钉里如果没有钉钉里已读功能的话，那基本上也是一个异步的一个写作过程，但是有了已读，相对来说会好一点点，单独来给一个重要的告诉你我ping 了之后，ping 到了。但是有没有回收利用的事，所以在过程当中一个异步。开发这样的一个角度。需要有一套一个相应的一些研发模式来去保证协作过程当中能够持续的把信息快速的响应掉。因为之前曾经提到过，就是软件交付过程，本质上是开发者围绕代码库的一个协作过程。
无论产品代码配置。环境还是发布流程，都可以代码化，都可以放在代码库里。整个软件交互协作过程，其实就是开发者围绕代码库的一个协作过程。这就带来了另一个结论，就是研发模式本质就是为了能够约束在围绕代码库工作的一些行为，其实本质是一种行为约束，然后是围绕代码库来产生的。
其实前面说的全部都是因为代码的提交，代码库的行为所产生的一些冲突，所以今天可能要跟大家聊的就是研发模式，把它狭隘定义要去做一些相应的一些行为约束，比如分支的类型应该有哪些，用这样的方式来去标识，另外一个分支的生命周期是怎么样来确定哪个时候创建，哪个时候做消防，那另外一个呢？Commit在分支之间是怎么来去流转的，彼此的约束有什么样，比如在开发分支和主干分支和精神分支和发布分支之间，是怎么来去做相应的一些同步。另外一个就是本身分支和代码极限的一个对应关系是什么样，所以今天会从这几个角度来去一起来去跟大家来去探讨一下，研发模式，也就是说我们的分支模式的一个协作过程。
四、研发模式
来看一下，其实研发模式，是一系列的研发行为的一个约束了。
追求的目标就应该是避免冲突，减少等待，因为刚才说其实在协作过程当中，人越来越多，其实带来最大的问题就是冲突很多，等待很多，所以应该好的研发模式，或者分支模式，应该是尽可能的避免冲突和能够尽可能的减少等待的，怎么来去做到这些事情，先看一下研发模式和研发行为之间的一些对应关系是什么样的一个对应关系。来看一下这些研发行为和代码库的行为的一个关系：
首先来看一下，开始一个新的特性，开发的时候，拉了一个特训知识，，一般会先创建一个新的French，然后再切过去，提交一次代码的集成，是一次commit和push。然后完成了之后进入集成的时候，就做了一次merge，那同样的集成完了之后进入待发布也是一样的，莫尔阶段最后发布之后，只是打一个tag，对于这里其实发现代码库里命令，这些行为，其实记录了一些研发型。所以本身研发行为和代码库的行为。那如果要去避免冲突和减少等待，应该怎么做呢？
唯一的最简单的方法就是不在一个地方，就是工作隔离开，就没有冲突了。所以在代码里，很多时候通过分支的方式来去做相应的一些工作之间的隔离，来去避免冲突，减少等待，等待是信息不同步造成的，就尽可能及时的做信息同步，所以就不用等待那在代码里的信息同步，是代码之间基线的这些同步。所以要做平凡的提交和位置，现在已经简单了解到了分支其实是用来避免冲突，是用来做工作隔离，频繁的提交合并是用来做信息同步，是为了避免等待，通过这样的一个简单的一个逻辑，来去看一下，如果是一个人做软件开发用什么样的分支模式呢？
