技术领导力实战笔记_190_第153讲_|_施翔：如何打造7*24高效交付通道（下）
你好，我是阿里巴巴高级技术专家。
施翔。
研发效能的提升是技术团队都需要关注的话题。
而打造一个七乘二十四小时的交付通道，就是一个非常有利的着眼点。
在整个交付通道中，架构配置、测试发布是提升效能的几个关键点。
上一篇文章分享了我们在架构配置这两个环节的做法，今天将继续分享我们在测试、发布等环节的实践。
先来看测试高频率、低成本，在架构配管以及打通的基础上，接下去就到了测试环节。
其实当一个技术团队比较小的时候，测试环节并不是那么必要。
当业务发展到一定规模，用户对于质量的容忍度越来越低的时候，才需要去引入专业的测试环节。
另外在过去传统软件是离线交付的模式，软件的交付程度非常高。
所以对于测试来说，它是不惜余力的，哪怕要花费更多的时间，更多的精力也要把测试做好。
这一在在互联网模式下，更多的软件是在线交付的模式，测试团队的角色也发生了一些变化。
以前，他可能是一个守门员守在研发环节的最后一道关口，把控软件的质量。
而现在它需要考虑怎样才能尽快对软件质量进行反馈，这是非常关键的一点。
但一点也决定了测试成为了整个研发交付环节中非常重要的一个环节。
测试包括单元测试、功能测试系统、测试集成测试、回归测试等不同的方法。
今天我想重点分享的是集成测试。
对测试来说，发布越频繁，对集成测试的要求就越高，越需要可靠低成本的集成测试方案。
上一篇文章中，我们提到代码分支管理有两种不同的策略，一种是分支开发主干发布，一种是分支开发，分支发布，它们其实就对应着不同的集成策略。
第一种策略，通过项目过程中不断的墨止，不断减少分支和主干的冲突，来提高项目间的集成效率。
在这个过程中，也可以用项目过程中的功能测试来覆盖小集成的需求。
第二种策略用空间换时间，多个项目一次性集成，提高单次集成效率。
在这种策略下，必然会有多个项目在集成区域等待，甚至可能有的项目提前一天就等在集成区了。
除了能提高单次集成的效率外，这种模式还适用于比较复杂的系统。
例如，阿里的一些业务系统，需要从端到端的验证的时候，就需要这种集成方式来确保他们从端到端的同步。
第三种策略无人值守，集成测试回归本质，通过测试技术手段来解决多项目集成过程中的频繁验证的问题，这也是更能保证测试灵活性的方式。
同时，作为技术人，我们会希望通过无人值守自动化来解决合并过程集成过程中的一些质量效率问题。
也只有这个问题解决了，我们才能一步一步往下打通到测试环节，不再让人的效率问题影响到整个交付通道的效率。
再来看，发布更灵活可感知。
在互联网行业，相信不少技术团队都遇到过这样的情况。
就是无论你开发上线速度有多快，业务同学总希望你们更快，甚至可能会出现一些变态的业务需求，比如要求一天开发一天上线，那怎么办呢？其实我们是可以在发布上下功夫的。
举个例子，阿里现在有很多发布模式，比如正式发布、beta发布、预发布、分批发布、灰度发布、隔离发布等等。
我们也希望如果有一天业务真的紧急到了这样的程度，需要第一时间上线的时候，我们可以通过这些灵活的发布方式来解决它的效率问题。
下面聊聊阿里CBU技术部的一些实践。
说了那么多理论，接下来我将分享我们CBU技术部在打造这个七乘二十四小时交付通道中的一些实践。
先来看分支管理和发布策略，如下图所示。
这是我们整个的发布通道，采用的是分支开发分支发布的策略。
对于整个发布通道，我们定义了四个流程状态，其中第一个是正常的，从预发到正式发布的环程，其间有开发构建预发正式发布、提交写基线到结束的整个从预发到发布的过程。
而第四个就是相对快速一些的发布通道。
从开发构建到正式发布，相较于第一个流程，它省去了中间一些预发的环节。
再来看无人值守自动化能力的建设。
我们讲协同的时候，通常指两方面，一个是人与人之间的交流协同，另一个是系统与系统之间的协同。
而我们做的就是第二种强调系统之间的协同。
过去常说，我们是面向过程来开发，面向对象来开发，面向服务来开发。
未来我们应该是面向平台来开发，以无人值守自动化系统为。
例如图中所示，上面是整个a one研发平台，开发者可以在这个平台上提交代码，进行预发代码，集成代码静态扫描乃至预发等等操作。
而当系统到了预发的状态后，就可以通过一些操作触发下面一层的自动化体系，并通过这个分层的自动化系统及时进行反馈。
我们对自动化的要求是，任何一次集成，任何一次发布都需要在三十分钟内跑完所有的用力，并给到a one平台分块，通过彼此系统间的交互解决效率问题。
我这里有一些自动执行的数据。
截至目前为止，我们整个部门中百分之五十左右的发布是完全由自动化实现的，基本不需要人力参与。
另外，去年一年通过这个自动化系统，我们线上拦截了三十多个问题数据，预发拦截了六十多个问题数据，日常拦截了一百多个问题数据，同时构建次数达两万九千多次，活跃功能测试件数量达一千一百多个，运行的case数达八万多个。
之前提到整个交付通道打通以后，我们从拉分支到正式发布的平均周期缩短到了五点二九天。
目前整个部门的应用数有一千多个开发人员，有三百五十多人，一年下来集成自动化大概是两万九千多人发布，大概是一万五千多次。
这些是非常优秀的数据，但可能对于老板来说，光有结果不行，还需要有过程。
为此，我们专门打造了一个部门提效中心。
我们做任何工具，任何平台都要考虑他们到底能不能产生价值。
那怎么衡量和定义这些工具平台的价值呢？我们想了一个最简单的方法，比如自动化，以前通过人肉去集成的话，可能需要一个小时。
现在自动化之后，通过工具或平台去执行集成的话，可能只需要十分钟。
那么对于这个工具或平台而言，就是执行一次提效五十分钟。
我们通过这样的方式去衡量整个提效过程的成果。
可以看到过去一年我们大概提升了两千一百七十七个人日，基本占了部门总人日的百分之五。
结语，回顾一下，我们通过架构的升级，极大的激发了开发同学coding的活力与能力。
通过平台化系统化，解决了配置、测试环境等问题。
通过无人值守的自动化集成测试，解决了集成质量与效率的问题。
通过灵活可感知的方式，解决了随时随地发布代码的问题。
这样一条路走下来，大家会发现其实整个交付通道已经打通了。
也就意味着，除去开发时间，任何一款代码都可以在七乘二十四小时内的任何一个时间点快速上线，解决了之前可能出现的排队发布时间长、集成测试效率低等等一系列问题。
这就是我们这么看重交付通道打通的原因，感谢收听，我们下期再见。
如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。