你好,我是阿里巴巴高级技术专家施翔,今天想跟大家一起探讨如何体系化的看待研发效能,以及我所在的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团队负责人。曾就职于中兴、支付宝等公司,在系统高可用、测试工具研发、研发效率提升等方面有着丰富的经验。