开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：为什么团队规模越大，发布反而变慢了】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1282
为什么团队规模越大，发布反而变慢了
内容介绍：
一、协同交付流程的概念及问题
二、研发模式的本质
三、研发行为与代码库行为的对应
一、协同交付流程的概念及问题
先给大家举一个例子，有一家企业创业开始时的规模只有八个人，那个时候他们每个月可以发出一两个版本，然后他们发展特别快，后来整个团队的规模到了80个人，但是他们半年都没有发出一个版本。所以说这个时候就发现了一个悖论，就是说我们以为团队规模越大，研发效率就会越高，就可以做更多的东西，但是发现团队规模大到一定程度的时候，整个研发效率是会下降，而且会下降的很快，比如图所示。
所以说为什么团队的规模越来越大，发布反而会越来越慢呢，这是一个很严重的问题。
其实站在很多团队的角度来说，因为人数增加了之后就协作会越来越慢，因为协作的成本越来越高。但是站在讲工程的这一块角度来说，这里不谈项目管理，更多是站在工程师的角度来看，我们每天面对代码，面对要去发布，要去开发的需求，在这样的场景中会发现团队的研发模式越多，越会有问题。因为冲突越多，等待越多。我们这里指的冲突，指的是代码集成发布过程当中的冲突，等待也指的是集成过程当中，开发过程中的一些对开发过程当中，代码彼此的一些等待。
看上面两个具体的场景。第一个场景是：假设有两个程序员 A 和 B 一起工作。
A 一开始每次提交都是好的，他把他的工作逐渐的提交到他的分支上去，这个时候 B 提交了一个版本，但是这个版本导致这个分支的编译失败。这时候 A 就不能提交，因为他提交也会失败，所以他就必须等待修复这个问题才能提交，那这样的话 A 的提交就跟 B 的工作产生了冲突。
第二种情况：既然两个人在同时去干活会产生冲突，那就拉开让每人做一个通知。结果 feature-A 先合进主干，然后 feature-B 晚了一点，结果发现不能合并。因为他们的基线不一样，这个时候就有代码冲突，那么就要先把冲突解决了，B 才能合并进去。
所以这就是两种常见的冲突的例子。
那么它的本质是什么？我们以时间轴的维度看，假设有三个人，A,B 和测试 C 。每个点代表他们做了一个任务，比如说 A 一直在干自己的事情，他每完成一个事情，就开始做下一个事情，结果他做完第三个事情的时候，发现需要找 B 联调一下。
他就给 B 发送 ping ，但是 B 有自己的节奏，他也在忙自己的任务，这个时候他并没有马上去响应 A 的请求，这时 B 发现他有一个任务可以提测了，所以他就告诉 C ，发送一个ping。C 看过之后发现其中有问题，于是马上回复 B , 发送一个 pong。但是这时候 B 因为自己的事务没有响应，然后 C 没有收到回复便又发送一个 pong 。这个时候 B 看到了，但是他先处理了 A 的事情，所以给 A 回复了一个 pong ，所以我们就发现，程序员和程序员，测试人员和开发人员之间在整个开发协作中,其实是一个异步的，延迟协作的过程，并不是你给我一个请求，我就能马上回复你，每个人往往会有自己的一个步调和任务，然后可能会延迟告诉你。所以当这个产品比较复杂，比如说产品上协作人数比较多，当团队比较复杂，也就是团队的人数比较多的时候，协作成本就快速的上升了。
现实中举一个钉钉的例子，如果说钉钉里头没有已读功能，那它基本上也是一个异步的协作过程，但有了已读之后，相对来说会好一点。能够告诉对方我的 ping 发送到了，但是对方有没有回复就是另外的事了。
二、研发模式的本质
所以在这个过程当中，一个异步的、延迟协作的这样的过程，需要有一套相应的一些研发模式，去保证在协作过程当中能够把信息持续的同步到，快速的响应掉。
我们之前提到过，软件交付过程本质上是开发者围绕代码库的一个协作过程，因为无论是产品代码，配置环境还是发布流程，都可以代码化，放在代码库里。所以整个软件交付协作过程就是开发者围绕代码库的一个协作过程。这就带来了另一个结论，研发模式的本质就是为了能够约束我们在围绕代码库工作的一些行为，也就是一种行为约束，围绕这个代码库来产生的。
我们前面讲的全部都是因为代码提交代码库的行为所产生的一些冲突，所以我们今天聊的就是研发模式，在这里把它狭隘的定义成我们的分支模式。
在这里，要去做一些相应的一些行为约束。那么都有哪些行为约束呢？比如分支的类型，应该用什么样的方式来标识它。另外一个就是分支的生命周期怎么来确定，什么时候创建、什么时候把它消亡掉。另外一个就是 commit 在分支之间是怎么流转的，它彼此有什么约束，比如说在开发分支和主干分支和集成分支和发布分支之间，它是怎么来去做相应的一些同步的。另外就是说本身你的分支和你的代码库的对应关系是什么样的。
所以说今天会从这几个角度来去探讨一下研发模式，也就是分支模式的一个协作过程。
其实研发模式是一系列研发行为的一个约束，它追求的目标就是避免冲突，减少等待。因为在协作过程当中，人越来越多带来最大的问题就是冲突很多，等待很多。所以说好的研发模式或者说分支模式就应该是尽可能的避免冲突和尽可能的减少等待。
三，研发行为与代码库行为的对应
那怎么去做到这些事情？看下图中所示的代码库行为和研发行为之间的一些对应关系。
首先，当开始一个新的特性开发的时候，我们是拉了一个特性认知，然后会先创建一个新的 branch 然后再切过去，比如说提交一次代码集成，基本上就是一次 commit 和 push。
完成之后进入集成的时候就做了一次 merge ，同意的话就说明集成完之后进入待发布，也是一样的一个的 merge 阶段，发布完了之后就是说打了一个 tag ，我们发现其实代码库里这些命令记录了我们的一些研发行为，所以说它本身研发行为和代码库的行为，是可以做到一一对应的。
那如果说要去避免冲突和减少等待，该怎么做呢？
其实避免冲突唯一的、最简单的方法就是工作隔离开来，这样就没有冲突，所以说在代码里很多时候要通过分支的方式来去做相应的一些工作之间的隔离来避免冲突。
减少等待：等待是信息不同步造成的，那就极可能及时的做信息同步，这样就不用等待，在代码里信息同步是代码之间基线的同步。所以说要做频繁的提交合并。
现在已经简单了解，分支其实是用避免冲突，是用来做工作隔离的。而频繁的提交合并是用来做信息同步是为了避免等待的。
