zoukankan      html  css  js  c++  java
  • 如何打造7*24h持续交付通道?阿里高级技术专家的5点思考

    我们对于研发效能的讨论,本质上是提高整个技术生态中的协同效率。如果仅从研发角度出发,技术团队要实现的终极目标是7*24小时的灵活发布窗口,以及更快的业务迭代能力。

    7*24小时发布窗口的实现其实并不简单,受限于很多因素。我简单的进行了分解。

    5cec8f79f4a805d8770c89e6ceb5483d20536cc3

    一、系统

    先从最基础的开始说,当一个创业团队只有几个人,一两个系统的情况下,是可以不考虑研发效率这回事的。因为不存在系统间的依赖,系统内的依赖也完全在一个可控的范围内,本地起一个 Tomcat 或 Apache 就能开发、调试。另外再加上团队成员之间的高频交流,基本上可以实现随时随地,想发就发的要求。

    f05b87f2249bdc5dfd405d5d18f65c369fb31000

    当业务逐渐复杂,开发人数扩展到10几人时。提效的第一步是理清系统内的依赖关系,并促进角色的专业化。这也是大家所熟知的MVC,通过对视图、模型、控制器的分离,对系统内的逻辑进行分层。把复杂的代码逻辑下沉到Model层,而视图层交由更专业的前端来负责。

    82e2e7cb8f1057bb79679ceed7871027b594105c

    当然,在系统内部仍然有一些扩展的空间,比如模块化,为不同的业务划分bundle等。但仍然没有突破本身的瓶颈,而且单一的系统也很难突破机器的特理特性。

    二、架构

    当技术团队已经达到几十上百人的规模,当业务已经无法通过单一的应用来进行水平扩展时。分布式的架构是解决问题的有效手段。在07年时,阿里集团就在推进SOA化,无论是淘宝还是支付宝,原来的单一应用不断被拆分出来,也在此时,承载服务化中枢的消息等中间件蓬勃发展。

    43cf6c1751f4f378c471de8b900e79a35af777df

    这种方式,实现了系统之间的解藕,激活了技术人员的生产力,同时增大了系统的弹性,实现了服务能力的低成本水平扩展。但因为复杂的调用关系,对于某一个贯穿多个应用的项目来说,无疑增加了集成的成本和质量的风险。

    同时,如果对应用规模不加以规划和控制的话,会导致应用数的不断扩张,从而影响到整体的开发维护成本。

    三、配置管理

    阿里在5到10年前,是有一个专门的岗位叫SCM的,负责技术团队内的代码管理,配置项管理和应用部署。特别是在服务化初期,开发人员的coding生产力被极度释放,应用数出现一个井喷,对配置管理的需求不断增强,并最终促使了配置管理的变革(截止到目前,专职的SCM团队被“消灭”了)。

    在讲配置管理前,先讲讲代码分支管理机制。这也是很多研发模式变革的起点。在此,我先表达自己的观点:没有对与错(先进与落后)的代码分支管理机制,只有适不适合自己团队当下以及未来发展的管理模式。

    先从大的层面上来说,我们当前所讨论的都是为了解决并行开发的问题,即有多个项目或团队对于同一系列应用进行功能开发。如果仅仅是串行开发,是基本不用太考虑代码管理策略。

    1、分支开发、主干发布。核心理念是使用固定的主干作为集成分支。使用分支进行开发,在合并到主干分支后生命周期终止。当然除此之外,还有紧急发布分支等。

    010d5fedc314ecbb519b2ebed41a59c9259ae0bb

    2、分支开发、分支发布。发布成功后执行写基线操作,确保主干的及时更新和稳定。同时分支发布的方式不依赖于大集成,保持很强的灵活性。

    a932c75e023bf59e1dab25433717d06c97e1e1f3

    体现在项目上的流程为:

    a1c2f9d84a356b7042d4607f73f7234533047763

    3、其他模式:主干开发、分支分布等。由于我们并不常用,所以略过。

    相关阅读:在阿里,我们如何管理代码分支

    平台化的支持:早期配管的人肉化,也造成了代码集成和部署的效率很低。不同角色之间的协同靠人来完成。因此在那个背景下,还需要一个配套的PMO组织来保障。在这样一个历史背景下,Aone(对外叫云效)也孕育而生,从平台化的角度来解决研发过程的协同、构建、集成和测试几个复杂的过程。

    为了更清楚的了解那个时期的痛点,我找了2009年左右的Aone(云效)的蓝图,可以管中窥豹(这个时期我并没有亲自经历过,只是针对于当时的老人做了些访谈和收集了一些资料)。我猜想也正因为这条道路面向未来解决问题造就了现在的Aone平台(云效)。

    a39c0e994ead429ac11770ac59327dbde7eb4cc0

    四、测试

    当一个技术团队小,负责应用少以及业务的用户群体少时,是完全可以不用测试的。只有当业务发展到一定阶段,用户对于质量的容忍程度越来越低时,才引入专业的测试角色。其次,在软件离线交付阶段,由于软件的召回成本很高,所以对于测试是不遗余力的,但随着在线交付时代的深入,测试团队是否能够快速的实现软件质量的评测反馈,成为一个非常关键的问题。而也决定着,在打通上述各个环节后,7*24小时软件持续交付通道是否能够真正实现。

    在讲之前,我们再回顾一下上个章节。Aone(云效)平台实现了开发代码、配置、应用部署的在线化,现在只剩下最后的一环——测试。从2010年以来,B2B的测试团队就希望可以把分层自动化平台跟Aone(云效)研发协作平台绑定在一起,通过系统调用的方式来实现一个测试的快速验证机制,并最终实现回归测试过程中的无人值守。

    76fd4426f997db3a6c72510e47e9be1bee76ee7d

    这个意义非常重大。应用的服务化后,技术的风险实际上是收敛的,大家都可以面向服务来进行开发,实现高内聚、构耦合。并且应用的发布也更加灵活了。但对于测试来说,却是极大的挑战:

    1、测试的层次增加了。

    2、测试的轮次变多了。每次集成,每次发布就有可能是一次完整的测试回归。

    8c8ada5bcfb6df3cca3487c37b3b759db1c1facf

    就如Aone(云效)的推进间接取替了SCM这个角色一样。研发平台的快速发展和业务7*24小时发布的述求,也开始冲击测试在代码集成后的快速反馈能力。这是一个挑战,也是一个机会。否则,前期释放出来的所有生产力,最后全都被卡在了测试这最后一个环节,而且没有办法拆解(每拆解出来一个,测试工作量就增加一倍)。只能通过不断叠加集成的应用量来提高集成测试的效率。

    66d02244133cb74ed647091c0db03de88d89d69a

    经过1688测试团队几代同学的努力,现在我们在这个方面总算有了些成绩。我们已经通过分层自动化体系实现了60%以上发布测试的无人值守,并且全年拦截故障在数百个级别(含页面、UI等)。

    28319bb141decb48b2b11d7d017e5dd33ae32c85

    它的实现逻辑如下:

    02ec7c5998ce16de9990cb7132d8d1d7ee2557f7

    五、文化

    至此,真正所谓的7*24小时业务的持续交付通道已经完全打造出来。

    80aace51d7c3caaf02df176c3021d1bc492c7488

    <Aone/云效流程图>

    我们再回顾一下:

    1、应用内的架构分层,前端、后端、测试各应其职,通过专业化的力量激发了一轮生产力。

    2、服务化的架构,让技术人员可以面向服务来进行业务的开发,实现了架构上的高内聚低耦合。进一步释放大规模技术团队的活力。

    3、研发平台的搭建,提供了持续交付管道,实现了开发、测试过程的快速、准确传递。

    4、依托于研发平台,实现了环境的自动化部署,应用监控,代码检查。扫除了研发过程的基建设施。让技术人员聚焦于代码的生产。

    5、测试自动化验证体系,减少系统集成风险,提高集成的频率。最终实现了代码的快速上线。

    作者简介

    施翔,毕业于南昌大学,现就职于阿里巴巴新零售技术事业群CBU技术部,担任高级专家职务,负责质量技术、系统稳定性和DevOps团队。过去曾就职于中兴通讯、支付宝等公司,善于通过技术手段解决研发环节质量问题,在系统高可用、测试工具研发、研发效率提升等方面有着丰富的经验。

  • 相关阅读:
    初等数论初步——剩余类及其运算
    初等数论初步——同余的概念及性质
    救济金发放(模拟题打卡)
    寻找最小字典序字符串(水题打卡)
    杭电3790最短路径问题
    Android网络请求
    js制造运动的假象-------Day63
    数据切分——原理
    Android 开发中 iBeacon的使用
    HDU 4869 Turn the pokers (2014多校联合训练第一场1009) 解题报告(维护区间 + 组合数)
  • 原文地址:https://www.cnblogs.com/zhaowei121/p/10173865.html
Copyright © 2011-2022 走看看