技术领导力实战笔记_189_第152讲_|_施翔：如何打造7*24高效交付通道（上）
你好，我是阿里巴巴高级技术专家施翔。
今天想跟大家一起探讨如何体系化的看待研发效能，以及我所在的CBU技术部在打造七乘二十四小时交付通道中的实践。
在开始之前想先跟大家分享一下我们的数据，毕竟没有数据的分享是没有灵魂的。
我们从拉分支到正式发布的平均周期是五点二九天。
目前整个部门的应用数有一千多个开发人员，有三百五十多人，一年下来集成自动化大概是两万九千多次发布，大概是一万五千多次。
平均下来可以看到每个人每年的平均发布次数是四十二次。
再细化一下，就是每人每周至少有一次发布，这个数据还是非常惊人的。
而这可以归结于研发效率。
再我们怎样从交付效道的角度思考研发效能的提升呢？所谓交付通道，就是从产品需求提出到最后触达用户的通道。
其中我们需要从四个维度出发考虑，即系统开发、测试、运维一系统。
怎样确保它可以无限扩展？编写代码过程中不受限于环境。
二、开发怎样能够不断的提交和验证需求？三、测试。
怎样快速的验证，快速的反馈？四、运维如何确保灵活的发布手段，更快更好的感知线上问题。
这个通道中的每个环节都应该自驱动自运行，而且各环节之间的工作传递也应该能够实时完成。
之所以从这四个维度来考虑，研发效能主要有三点原因，第一，主要是基于业务的长期诉求，希望技术能够快速的、高质量的影响业务需求，做好业务交付。
第二，在整个研发生命周期中，影响业务交付的因素有很多，因此需要我们从交付通道的各个维度出发来考虑问题。
第三，敏捷能力需要有持续性。
而在整个交付通道中，架构配置、测试、发布等是提升效能的几个关键点。
接下来我会从这几个点出发分享我们是如何打造七乘二十四小时交付通道的。
首先来看架构提升代码的生产力，影响代码生产的因素主要有以下几个方面，第一，代码结构是否合理。
第二，代码提交模块是否足够小。
第三，开发环境构建是否便捷。
第四，代码语言的适用性等等。
而好的架构能有效提升代码的生产力，但也需要结合团队的规模、业务特点等来决定更适用的架构。
比如，在创业阶段，技术团队只有几个人的情况下，完全可以在主干上进行开发。
在主干上进行发布不会有任何的影响。
因为系统之间不存在依赖一切在非常可控的范围之内。
在这个阶段甚至可以不用考虑架构的问题，不用考虑研发效能的问题，没那个必要，不用为了架构而架构，为了研发效能而研发效能。
当业务复杂团队已经达到几十上百人规模之后，我们就需要对系统进行分层。
比如MVC模式，就是把系统按照model模型view试图control了控制器来分层，让前端后端测试等更加专业的需求，去做更加专业的事情。
否则，如果所有的人都在一个平台进行开发，那么彼此之间一定会相互发分满。
且在解决一些代码冲突时，花费的时间可能比代码开发的时间还要长。
随着业务的不断发展，当系统分层也难以支撑业务发展需求的时候，我们不可能再在单台机器上获取一些性能的提升。
而是需要从技术的角度，通过裂变或通过调整架构来提升代码生产力。
比如阿里巴巴在二零零七年以后，整个系统SOA化调整为按照服务的方式进行划分，满足了业务去高速增长的需求。
同时这种分布式的架构也很好的解决了效率问题。
之前也提到，当所有技术同学都围绕着一个系统进行开发的时候，一定会出现冲突。
而当组件拆分之后，所有的技术同学都面向自己负责的服务进行开发，释放个人生产力，效率就能得到大大的提升。
如今阿里整个系统的规模一直在不断膨胀。
今天可能我们一个开发同学需要维护对应的两到三个系统。
这其实就是从整个系统架构的层面去考虑怎样提升开发同学的生产力，让他们的活力能够释放出来。
这也是研发效能提升的第一步。
再来看配管全天候的配置能力。
以前我们有个岗位叫SCM,负责版本控制、环境管理、配置管理等，来保证所有配置项的完整性和可跟踪性。
但当分布式架构、面向服务的架构蓬勃发展起来之后，系统的数量也在不断扩张。
以前的SCM是靠人肉来部署，但当系统数大量扩张之后，SCM就不可能再靠。
以前这种人肉的方式了，在配管中非常关键的一个点，是对代码分支的管理。
代码分支管理可以说是研发模式变革的一个起点。
它的策略不存在好坏之说，需要结合业务的特点、技术团队的规模等因素来决定。
对阿里来说，代码分支管理解决的核心问题是并行开发。
在实践中，具体的代码分支管理策略有两种，一种是分支开发主干发布，一种是分支开发，分支发布。
对于第一种分支开发主干发布来说，它可以维持一个非常稳定的主干环境，同时又可以随时拉一个新的分支出来进行独立的开发。
但这种模式也存在一个问题，因是所有的分支都必须要在一个集合点或者说集成区才能进行集成。
而且当开发人员在集成的过程中，发现代码有bug,需要回滚的时候，成本是非常高的，因为可能需要所有的分支全部重构才可以。
对于第二种分支开发分支发布来说，理论上这种模式拥有非常高的灵活度，可以确保每个项目不会影响任何一个项目，不同的项目组之间也不会相互影响，但它也会带来非常大的挑战。
主要在于这种模式需要有非常多的墨汁的过程。
而这些墨纸所带来的是测试工作量的急剧增长，需要非常频繁的测试，才能解决不断墨纸所带来的问题，确保集成质量。
以阿里为例，大概在二零零九年的时候，我们希望能够把代码开发、代码提及配置管理等环节，通过工具等方式进行集成，取代原先靠人来协同的模式。
在这样的背景下，我们打造了一个研发统一协作平台，a one对外也叫云效。
从平台化的角度来解决研发效率以及研发过程中的协同等问题。
在我们做了这件事之后，大家会发现原来的SCM团队消失了。
他们之前能做的配置、协同等问题，我们都能通过这个平台化的角度来解决。
而代码分支管理对应的非常重要的一点就是开发和测试环境的协同。
那a one的核心就要确保以下几点。
第一，环境必须能自动化部署，否则就又回到了之前人肉的时代。
第二，环境之间必须要有隔离。
当存在多套测试环境的时候，隔离协同等问题，就是平台一定要解决的。
第三，要确保测试环境的稳定性。
无论是开发同学还是测试同学，都需要在测试环境上做一些支撑。
怎么确保测试环境的稳定性就成了重中之重？小杰今天跟大家分享了我们在打造七乘二十四小时交付通道中的实践。
正如前文提到的，整个交付通道中，架构配置、测试、发布等是提升效能的几个关键点，尤其是架构与配置尤为重要。
在升级了系统架构提升了配管能力之后，开发同学的活力能得到极大的激发，他们可以无拘无束的面对自己的系统，自己的服务来进行开发活力被大大释放了。
同时，我们通过平台化来支持配置管理、测试环境、管理等解放人力，也能够实现七乘二十四小时战略支持，受限于篇幅剩下的测试、发布等关键环节的提升。
我将在下一篇文章中与你分享，欢迎持续关注，感谢收听，我们下期再见。
如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。