你好，我是阿里巴巴高级技术专家施翔，今天想跟大家一起探讨如何体系化的看待研发效能，以及我所在的 CBU 技术部在打造 7*24 小时交付通道中的实践。

在开始之前，想先跟大家分享一下我们的数据，毕竟没有数据的分享是没有灵魂的。我们从拉分支到正式发布的平均周期是 5.29 天，目前整个部门的应用数有 1000 多个，开发人员有 350 多人，一年下来集成自动化大概是 29000 多次，发布大概是 15000 多次。平均下来，可以看到，每个人每年的平均发布次数是 42 次，再细化一下，就是每人每周至少有一次发布，这个数据还是非常惊人的。

而这可以归结于研发效率，那我们怎样从交付通道的角度，思考研发效能的提升呢。所谓交付通道，就是从产品需求提出到最后触达用户的通道，其中，我们需要从四个维度出发考虑，即系统、开发、测试、运维。
1. 系统：怎样确保它可以无限扩展，编写代码过程中不受限于环境。
2. 开发：怎样能够不断地提交和验证需求。
3. 测试：怎样快速的验证，快速的反馈。
4. 运维：如何确保灵活的发布手段，更快更好地感知线上问题。

这个通道中的每个环节，都应该自驱动、自运行，而且各环节之间的工件传递也应该能够实时完成。

之所以从这四个维度来考虑研发效能，主要有三点原因：第一，主要是基于业务的长期述求，希望技术能够快速地、高质量地响应业务需求，做好业务交付；第二，在整个研发生命周期中，影响业务交付的因素有很多，因此需要我们从交付通道的各个维度出发来考虑问题。第三，敏捷能力需要有持续性。

而在整个交付通道中，架构、配置、测试、发布等是提升效能的几个关键点，接下来，我会从这几个点出发，分享我们是如何打造 7*24 小时交付通道的。

架构——提升代码的生产力

影响代码生产的因素主要有以下几个方面，第一，代码结构是否合理；第二，代码提交模块是否足够小；第三，开发环境构建是否便捷；第四，代码语言的适用性等等。

而好的架构能有效提升代码的生产力，但也需要结合团队的规模、业务特点等来决定更适用的架构，比如在创业阶段，技术团队只有几个人的情况下，完全可以在主干上进行开发，在主干上进行发布，不会有任何的影响。因为系统之间不存在依赖，一切在非常可控的范围之内。在这个阶段，甚至可以不用考虑架构的问题，不用考虑研发效能的问题，没那个必要，不用为了架构而架构，为了研发效能而研发效能。

当业务复杂、团队已经达到几十上百人规模之后，我们就需要对系统进行分层，比如 MVC 模式，就是把系统按照 Model（模型）、View（视图）、Controller（控制器）来分层，让前端、后端、测试等更加专业的同学去做更加专业的事情。否则，如果所有的人都在一个平台进行开发，那么彼此之间一定会相互等待，而且在解决一些代码冲突时，花费的时间可能比代码开发的时间还要长。

随着业务的不断发展，当系统分层也难以支撑业务发展需求的时候，我们不可能再在单台机器上获取一些性能的提升，而是需要从技术的角度，通过裂变或通过调整架构来提升代码生产力。比如阿里巴巴在 2007 年以后，整个系统 SOA 化，调整为按照服务的方式进行划分，满足了业务去高速增长的需求，同时这种分布式的架构，也很好地解决了效率问题。

之前也提到，当所有技术同学都围绕着一个系统进行开发的时候，一定会出现冲突，而当组件拆分之后，所有的技术同学都面向自己负责的服务进行开发，释放个人生产力，效率就能得到大大的提升。

如今，阿里整个系统的规模一直在不断膨胀，今天，可能我们一个开发同学需要维护对应的两到三个系统。这其实就是从整个系统架构的层面去考虑，怎么提升开发同学的生产力，让他们的活力能够释放出来，这也是研发效能提升的第一步。

配管——全天候的配置能力

以前我们有个岗位叫 SCM，负责版本控制、环境管理、配置管理等，来保证所有配置项的完整性和可跟踪性。但当分布式架构、面向服务的架构蓬勃发展起来之后，系统的数量也在不断扩张。以前的 SCM 是靠人肉来部署，但当系统数大量扩张之后，SCM 就不可能再靠以前这种人肉的方式了。

在配管中，非常关键的一个点是对代码分支的管理。代码分支管理可以说是研发模式变革的一个起点，它的策略不存在好坏之说，需要结合业务的特点、技术团队的规模等因素来决定。

对阿里来说，代码分支管理解决的核心问题是并行开发。在实践中，具体的代码分支管理策略有两种，一种是分支开发、主干发布，一种是分支开发、分支发布。

对于第一种分支开发、主干发布来说，它可以维持一个非常稳定的主干环境，同时又可以随时拉一个新的分支出来进行独立的开发。但这种模式也存在一个问题，就是所有的分支都必须要在一个集合点或者说集成区，才能进行集成。而且，当开发人员在集成的过程中发现代码有 bug，需要回滚的时候，成本是非常高的，因为可能需要所有的分支全部重构才可以。

对于第二种分支开发、分支发布来说，理论上，这种模式拥有非常高的灵活度，可以确保每个项目不会影响任何一个项目，不同的项目组之间也不会相互影响。但它也会带来非常大的挑战，主要在于这种模式需要有非常多的 merge 的过程，而这些 merge 所带来的是测试工作量的急剧增长，需要非常频繁的测试才能解决不断 merge 所带来的问题，确保集成质量。

以阿里为例，大概在 2009 年的时候，我们希望能够把代码开发、代码提及、配置管理等环节通过工具的方式进行集成，取代原先靠人来协同的模式。在这样的背景下，我们打造了一个研发统一协作平台 Aone，对外也叫云效，从平台化的角度来解决研发效率以及研发过程中的协同等问题。在我们做了这件事之后，大家会发现，原来的 SCM 团队消失了，他们之前能做的配置、协同等问题，我们都能通过这个平台化的角度来解决。

而代码分支管理对应的非常重要的一点就是开发和测试环境的协同，那 Aone 的核心就要确保以下几点：第一，环境必须能自动化部署，否则就又回到了之前人肉的时代；第二，环境之间必须要有隔离，当存在多套测试环境的时候，隔离、协同等问题就是平台一定要解决的；第三，要确保测试环境的稳定性，无论是开发同学还是测试同学都需要在测试环境上做一些支撑，怎么确保测试环境的稳定性就成了重中之重。

小结

今天跟大家分享了我们在打造 7*24 小时交付通道中的实践，正如前文提到的，整个交付通道中，架构、配置、测试、发布等是提升效能的几个关键点，尤其是架构与配置，尤为重要。

在升级了系统架构，提升了配管能力之后，开发同学的活力能得到极大的激发，他们可以无拘无束的面对自己的系统、自己的服务来进行开发，活力被大大释放了。同时，我们通过平台化来支持配置管理、测试环境管理等，解放人力，也能够实现 7*24 小时战略支持。

受限于篇幅，剩下的测试、发布等关键环节的提升，我将在下一篇文章中与你分享，欢迎持续关注。感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

施翔，TGO 鲲鹏会会员，现就职于阿里巴巴 CBU 技术部，担任高级专家职务，质量技术、稳定性和 DevOps 团队负责人。曾就职于中兴、支付宝等公司，在系统高可用、测试工具研发、研发效率提升等方面有着丰富的经验。