部门网站的开发 意义,wordpress post 钩子,做网站用,房屋建设设计网站摘要#xff1a; 阿里持续交付平台已经经历了 8 年的不断迭代进化#xff0c;成长为集团几万应用所依赖的最重要的研发工具#xff0c;它的效率直接影响着几万研发日常工作。但平台不能只是工具的堆砌#xff0c;更需要针对互联网时代的研发模式进行深度思考#xff0c;不…摘要 阿里持续交付平台已经经历了 8 年的不断迭代进化成长为集团几万应用所依赖的最重要的研发工具它的效率直接影响着几万研发日常工作。但平台不能只是工具的堆砌更需要针对互联网时代的研发模式进行深度思考不断打磨将工程师文化和工程师实践不断地融入其中。
阿里持续交付平台已经经历了 8 年的不断迭代进化成长为集团几万应用所依赖的最重要的研发工具它的效率直接影响着几万研发日常工作。但平台不能只是工具的堆砌更需要针对互联网时代的研发模式进行深度思考不断打磨将工程师文化和工程师实践不断地融入其中。轻管控重技术使用业界上最新工程实践用技术的演进去解决技术人的效率问题。本次演讲将介绍阿里持续交付工具的演化历程和对互联网行业交付领域热点问题的思考实践。
注本文整理自阿里巴巴高级技术专家陈鑫神秀在 ArchSummit 全球架构师峰会 2017 深圳站上的演讲原题为《互联网时代的持续交付》。
写在前面
大家好我来自阿里巴巴花名神秀今天给大家带来的 topic 是互联网时代的持续交付。为什么在持续交付前面要强调互联网阿里的持续交付实践有什么特别之处希望我在这里能够抛砖引玉给大家带来一点点收获。
我在阿里负责持续交付平台和研发工具链建设以及将对应的能力通过阿里云输出我们对外的版本叫云效公有云上目前正在公测中。
首先给大家介绍下今天的几个主要内容。
首先着重介绍一下阿里这些年持续交付工具上的演进和我们的建设思路。 然后会和大家一起探讨一下互联网企业产品快速演进下的一个重要话题质量和效率介绍我们怎么看待这两者之间的关系以及如何协调。 再一个是我们正在面对的问题交付和 devops传统软件企业对交付肯定不陌生但对于阿里场景下我们会有一些新的挑战。Devops 方面介绍下我们最近一年的进展和一个小创新。 发展持续交付在阿里
时间线
首先介绍下阿里持续交付平台的发展历程第一阶段2009 年我们做了一个简单的自动化发布工具来解决 SCM 和 PE 同学单点问题。在这之前可能很多企业都经历过这样的过程固定时间提交发布申请配管同学开始统一冻结代码打包然后交给运维同学进行发布。在小团队小企业时也勉强够用。应用规模越来越大线上环境越来越复杂时配管和运维同学的能力和效率开始阻碍我们产品的发展。当然其中也有一些腐败比如要搭车紧急发布要请配管同学喝咖啡什么的。开个玩笑。
没过两年研发人员越来越多各种复杂研发规范线上各种复杂脚本各种新同学挖坑后人踩坑苦不堪言。这一切必须规范起来后来到了 2013 年我们把从代码变更到线上发布完全统一了起来通过统一构建部署平台进行严管控。
显然这还远远不够到了 2016 年平台再度升级。上线了从需求到代码从交付到反馈的一站式平台。项目、需求、代码、构建、测试、发布、流水线、舆情反馈等等等等产品大图基本完备。
在 2017 年我们把这 8 年的平台工具经验开放到了阿里云也就是云效这个产品希望通过阿里经验反哺云上生态同时也依托广大研发者的经验帮助我们工具成长。
工具与理念演进
说完了发展历程下面介绍下我们的工具和理念的演进过程下面会针对这四点详细展开。
第一是自动化自动化是工具首先要完成的价值也是效率提升的最直接的抓手。对于我们会先做好配置、代码、测试、运维的自动化。 第二是标准化标准化是工具平台最大使命比如亚马逊经常讲到的Apollo环境部署工具就做的非常棒阿里也有自己的研发标准和运维标准研发标准中比如研发模式、技术栈、配置管理规范相对好做。运维域就相当困难目前 web 应用、移动应用、搜索、系统基础软件等会自成体系集团内部和阿里云也会略有不同。但是随着容器化和统一调度的推进这些都有望统一。 第三是定制化定制化应该是对平台的更高要求不同团队不同技能水平对工具天然就有不同的需求。我们不能因为管控而丧失灵活性也不能因为照顾低水平技能而限制高水平。因此我们会首先按照团队成熟度来推荐适合的交付过程和管理规范。 第四是一站式当工具开始百花齐放时对研发同学是有一定伤害的不同的交互不同的产品对接形态不但会增加系统复杂度也让效率在平台之间的流转中降低。因此我们通过平台工具融合将需求到反馈的整条链路打通在一个平台完成基于价值的交付。
自动化一切好先看下我们的第一个理念自动化一切。这张图展示的是一个常见的研发过程我们先从 master 拉出开发分支进行开发合并成 release 分支进行发布发布完成后合并到 master。应该每个研发团队都有自己的一套规范来处理分支问题。当团队规模越来越大或者出现新人的时候如何规范操作提高协作效率避免错误那么就需要工具来承载这一切。
我们将常见的几种研发模式主干开发、分支开发、gitflow 等从拉分支开始到 mergerequest、代码合并、冲突解决全部白屏化解决最终简化成一个 pipeline一个开发新手只需在平台上操作就可以马上融入研发工作而不会出现任何差错。
标准化落地
再看关于标准化方面工具层面主要完成了这几个方面应用创建、测试验收、标准环境、上线卡点、部署过程。
一个应用对应一个代码库一个服务单元我们通过代码推荐、技术栈模板对集团标准进行落地和迭代比如 springboot 推广。通过资源编排来快速完成基础设施的申请搭建。
测试验收方面集团规约和安全测试是这几年主推的标准已经在全集团落地代码质量得分则是通过数据度量的方式客观评测当前应用质量情况。
标准环境是交付流水线和运维管控的基础通过容器化和统一调度现在可以比较容易的实现第四点比较有意思。原来的工具思路往往是出现部署、资源问题会引导用户通过自动化工具自助解决比如清理日志、重启机器等。现在我们会更多的采用自愈的方式把环境资源运维工作下沉到平台无人干预式解决用工具替代人。
上线卡点多是一些管控类需求基于集团统一的管控策略来定控制研发行为和质量。
最后部署过程发布策略、监控、基线、回滚都是必备功能我这里就不再赘述了。
定制化解决方案
要实现定制化先看下解决方案的几个因素
团队成熟度规模如何1-2 人7 人10 人以上全栈还是有独立测试运维团队质量如何是否有技术债务团队内部有什么特别的规范约定 迭代速度每日随时发还是周期性交付是否有窗口限制从我们持续交付的角度我们并不想对上线行为做过多约束符合卡点应该即可上线阿里现在核心应用基本都做到随时发布甚至一日多次发布。 BU 技术栈各自 BU 的一些私货规范和个性化差异。虽然我们一直在建设统一基础设施和研发运维平台仍然无法做到 100% 统一是我们一直努力的方向 最后是集成交付是否有产品集成需求项目交付或者专有云交付。比较典型的就是电商、移动端、阿里云三种形态。 由这四点因素我们推导出了几种定制化方向
研发模式根据应用小规模团队采用分支研发共建型大团队采用 gitflow更加庞大的团队采用主干开发模式。因为微服务设计的流行现在应用的团队规模越来越小所以在阿里分支研发模式会更受欢迎。 技术栈java、C、脚本类等等我们会采用代码推荐和模板化的方式帮助用户一键创建代码框架和编译环境。 部署模板常见的做法是软件包模板和 Dockerfile。在阿里很多 BU 架构负责人和 PE 都会提供各种技术栈基础镜像帮助普通研发者快速部署环境类似这种的技术栈管控也同样依靠工具来承载。 最后依靠多级 pipeline 来实现多种类型的交付过程来满足集成交付需求。
一站式平台大家现在看到的是目前阿里云效研发协同平台的全貌总体可以分为项目协作和持续交付两大部分交付部分形成了从需求到反馈的完整闭环其中反馈部分不单单只有效能度量还有针对业务本身的舆情分析和问卷调查以及智能化客服工具。
工程师文化落地平台
最后说一下我们建立平台工具的最终目的就是将工程师文化落地平台。当然工程师文化是一个很虚的东西每个企业都有自己的文化。包括阿里自己内部淘系、B2B、阿里云等 BU 都有各自特点。不过总结下来会有以下四点
质量文化质量是持续交付的核心所在团队成长的必经之路。没有质量的文化传承效率无从谈起代码会很快腐烂无人敢动成为技术债务。更不要说快速迭代和持续交付了。 创新文化作为研发中台的我们不可能也不必要成为所有工具创新、效率创新的来源。在阿里本身也有浓厚的创新文化今天我们碰撞出一个 idea明天就有一帮哥们把他变为一个工具或者小产品。创新被人发现后还会快速的发展成一系列生态。这些事情每天都在发生对于我们工具平台来说应该成为一个载体将最优秀的创新落地在平台之上促进相似产品的融合避免重复造轮子也可以推广引流做强做大形成正向循环。 全栈文化现在都在讲 devops但没有工具承载的 devops 基本上是空谈当我们平台可以帮助 dev 自动完成 ops 工作或者引导促进知识学习时才能做到研发、测试、运维协作的无死角。 精益文化这个才是我们一站式平台的理念所在基于价值的交付基于数据的准确度量帮助开发或者领导者评估产品价值和优化团队效率。 好以上就是我们对阿里内部研发工具建设上的一些实践希望能够抛砖引玉共同探讨。
两大挑战质量和效率
接下来我们探讨一个话题质量与效率这可能是工程领域一个永恒的话题我们今天就聚焦在互联网场景下我们的软件怎么来解决既要又要还要的问题。
先看下在互联网时代我们的一些挑战
当交付速度决定市场我们 CTO 曾说过研发工具要保障一个 idea 从诞生到上线在 2 周内完成快速试错不行就干掉好了就拉一帮人做大做强。对于传统研发方式来说这似乎非常困难但是却真实发生了。
在这个前提下我们的质量效率将如何选择
开着飞机换引擎会成为常态基于我们前面的假设先占领市场再不断迭代优化基本已经成为我们软件研发的共识。现在如果有人说我们是开着飞机换飞机我可能都只能“呵呵”一声因为我们自己就经常这么干对吧。
持续集成面临挑战
再来看我们持续集成面临的挑战
缺少测试覆盖的持续集成成为负担。当我们单测、API 测试做的不好的时候通过流程强加的持续集成基本上是自欺欺人要不就是不稳定要不就是没效果。 测试团队转型开发全栈导致的质量下降。有这么多需求没时间写测试或者保姆式服务享受惯了自己没这个意识等等等等。 测试环境互相依赖产生不稳定因素在阿里集成环境问题应该是研发过程中的一大痛点。 看了这么多问题我们需要思考除了推动完善测试我们还能做什么
从工具要效率
好我今天要讲的是从工具要效率质量与效率并重。首先我们看下我们从哪里能获得效率
第一个快速反馈我想对于效率我们首先能想到的词是快也就是快速反馈。加快构建速度加快回归速度。 第二个是协作因为往往沟通成本是程序员的一大开销而且咱们还不太擅长对吧经常会发现 IQ 和 EQ 成反比。因此降低协作成本可以有效提升效率比如分支开发模式在线审核移动办公等等 第三个是创新原有粗放型人力型无法延续的时候创新可能是唯一出路。比如双引擎测试、mock 测试等等。 以上三点我会一一举例来介绍。
协作成本先来看一个协作的例子分支开发和主干开发这两种研发模式的对比。
所谓分支开发就是所有人都在分支上进行编码比如需求bug 等等需要集成时合并到一个临时 release 分支上进行打包发布发布完成后合并到主干。
所谓主干开发即开发者直接在主干上进行编码开发完成后立即提交主干发布时采用最新主干代码进行打包发布。
好接下来我们看下两种研发模式的对比
首先看是否建立分支的区别。分支开发模式每个 feature 都建立分支利于管控看到分支马上明白是做什么事情。主干模式直接提交主干通过 commit 来区分。 第二点分支研发需要多次集成合并 release必然会产生重复冲突集成后测试会导致测试反馈滞后。而主干开发则只需解决一次冲突可以做到提交后即集成。 第三点当某个分支功能不想发布了分支模式可以直接退出集成需要发布的分支重新合并 release 即可。而主干开发往往采用特性开关方式 off 掉相应功能因为代码剥离比较困难。 第四点当线上某次发布被回滚掉了分支模式我们可以把主干进行回滚下次 release 分支合并时即可自动回滚防止错误代码被重复发上线。而主干模式需要进行 hotfix在此之前可能会 block 后续发布。 通过以上四个场景的对比我们把相对利于协作的标为黑色不利于的标为白色。可以看出分支模式似乎略胜尤其是在第三点基于功能分支的任意集成给研发同学提供了很高的自由度。我们实践下来通过工具化支持在微服务人员分工明确耦合较少和快速迭代的场景下大大减轻了分支开发集成反馈滞后的弊端。
快速反馈
好我们看下一个效率点快速反馈。研发过程中随着测试用例逐渐积累测试时间也随之增长执行时间到 30 分钟时我想应该都忍不了吧几杯咖啡都下肚了测试还在跑好抓狂。这里我要介绍一个做的比较有意思的工具来达成快速的这个目标我们叫他精准回归。他有几个特性借助中间件全链路 trace 技术建立测试用例与业务方法的关联关系当代码变更时推荐需要执行的用例精准回归快速反馈。
架构图来看下这张图。首先我们通过 eagleeye我们用于 tracing 的中间件插件来对测试代码和应用代码进行打桩注入 taceid。当测试用例执行时我们记录测试用例到应用代码的完整链路日志也就是 eagleeye log通过日志采集送入实时计算引擎计算出测试代码和应用方法之间的关联关系。
打个比方当我们掌握了一个测试用例覆盖了哪些应用代码后当代码发生变化后自然知道有哪些用例可以覆盖到他这样只要执行这些用例就好了几十分钟的测试时间缩短到几分钟甚至数秒对于效率提升会非常巨大。
当然这个方案也不是一点瑕疵也没有在集成阶段我们推荐运行完整用例集不过这个没关系毕竟在开发阶段测试运行的频度要大于集成阶段。
测试创新
先看三个问题测试覆盖不全怎么办写测试用例尤其是好的用例需要大量时间。beta 测试会产生资损故障怎么处理真实流量进入后如果有 bug肯定会导致一些问题虽然影响小但是也会导致一些不可弥补的问题。测试数据难以维护经常被污染怎么办这是一个复杂而头疼的问题。
为了解决以上问题天猫业务团队诞生了一个叫双引擎测试的平台通过线上数据采集线下服务隔离执行重放和对比自动完成回归工作辅助我们提高覆盖率大大提高效率。
架构图大家可以看这张架构图左边是线上服务首先通过 client 对线上请求进行采集其中包括 request 和 response以及下游系统缓存、db 等等的调用链路快照。通过 mq 消息发送给 beta 环境的 client 进行回放。
这里就简单进行回放请求就完成了么显然不是该工具最核心的是对应用所有的下游依赖进行了隔离和 mock比如应用发送给 db 一条 sql 查询数据双引擎测试平台会将这个请求阻断并返回线上同样查询的快照数据。最终拿到应用的 response 进行实时对比存储不一致结果。
通过这种机制我们可以轻松实现线上请求线下回放测试debug专注测试业务代码本身隔离依赖避免干扰。
在这个工具上面我们还可以长出很多比如用例管理、失败分析离线回放等等产品目前该平台在阿里已经形成了自己的生态圈落地核心应用并且保障了多次核心代码的重构升级工作。
交付挑战与 DevOps 实践
前面我们介绍了阿里持续交付过去的一些实践现在的质量与效率挑战下面我会讲一下我们当前正在做的和正在探索的两个方向交付和 devops。
国际化和私有云的转变
说到交付这个话题传统企业一定不陌生而且可以说是绝对的专家。现在阿里这样的互联网公司面临着新的交付问题。当我们要把电商体系附能给合资公司怎么办我们要把基础设施和完整阿里技术体系输出该怎么办当我们应用巨多形成网状依赖以后怎么办听着就是一个很庞大的事情是不是
目前我们的两个交付变化从统一交付变为分批交付比如我们先输出电商中台再输出电商上层业务应用。从整体交付变为分块交付当全部输出后要进行版本迭代如此大的应用规模无法在做整体交付此时就需要进行分块交付。而且这个块可能每次都会存在差异。这无疑对工具带来了新的挑战。
交付效率挑战我们接着说效率我这里列了三点
快速搭建我们需要低成本的一键创建环境复现问题或者创建交付版本的集成测试环境。 测试回归当环境中存在多个版本服务怎么搞而且怎么做到足够得快 链路管理交付的过程能不能做成一键式交付的版本能否可视可控避免交付风险。 下面我们针对以上三点举例说明。
交付过程探索在这里我把交付过程写到了这个 pipeline 里依赖识别对比回归快速搭建精准回归一键交付。
首先看依赖识别为什么要做依赖识别刚才提到了当我的应用数量非常大并且网状依赖非常复杂时让人来识别依赖关系已经不靠谱了。而且我要交付一个功能如果牵一发动全身的让所有关联应用来次整体输出涉及的团队太多基本也不可持续。因此一定要工具来完成自动的依赖识别。借助全链路调用数据完全可以做到这一点。
比如我修改了 A1 这个版本通过链路数据结合交付端链路快照发现必须顺带着交付 B1 和 C1 两个版本此时系统帮我圈定了一个交付集后续的测试工作可以基于此来开展。
集成测试开始前我们可以借助刚介绍的双引擎测试平台进行数据回放对比测试确认对交付端数据的影响。
集成测试
接下来我们将进入集成测试阶段首先是快速搭建通过应用容器编排基于中间件隔离我们可以很轻松的将 A1、B1、C1 进行隔离形成一个小的集成链路。通过精准回归技术对变更功能进行快速反馈。
一键交付
最后是一键交付除了基本的版本管理能力以外我还可以在集团环境直接管理交付端的环境让研发人员交付过程成本降到最低。同时在交付端支持灰度发布能力进一步减少交付风险。
最重要的还是有通畅的反馈渠道依靠在前面介绍的平台产品大图上反馈模块的丰富功能比如舆情、问答我可以快速掌握交付端情况采取必要措施。
好以上就是我们针对目前新的交付问题的一些做法欢迎各位与我深入探讨。
DevOps 之路关键是工具
最后一个话题 devops在这里我并不会详细展开只是讲下我们这一年多来 devops 转型的一些心得和一个小创新。
从 15 年开始提转型阿里集团去掉了大部分业务的 PE 团队交给开发16 年我们建设统一调度平台和落地 docker 容器技术并完成了核心应用升级。17 年可能会是 devops 在阿里最辉煌的一年今年我们会完成所有活跃应用的容器化和上下游完整工具链建设。
在这里我列了三点首先对研发来说最基本的 ops 是什么应用配置、环境、软件基线线上变更再加上流水线的管控。这是天天在用的。
这么复杂的一套在容器化之前我们做的并不好当容器化开始落地后我们的环境进一步标准化实现了代码驱动变更管理工具大幅简化。以前的基线工具软件包校验工具批量执行工具都不需要了。并且通过配套调度系统将环境资源真正交到了研发同学手里。
运维系统开始化繁为简服务下沉自助型操作转为自愈型并且开始尝试智能化解决方案。比如大促弹性调度。
DevOps 在阿里
看起来很美好是吧实际上呢不可否认Ops 对开发者是有相当大挑战的尤其是相关运维基础知识的缺失解决问题能力的缺失。简单地将 Ops 交给 Dev 就是 DevOps 了么显然不是这不但对开发是一种伤害还是一种效率低下的做法以前 1000 个人能做的事情现在需要 10000 个人来完成。
因此我们不能让 DevOps 成为负担DevOps 机器人在路上。
DevOps 机器人Devops 机器人实际上是基于数据的主动服务机器人来随时帮助开发者补充知识解决问题并且我们有一个机制来确保知识获取的自闭环。
首先数据来自哪里常见的构建错误机器上错误日志部署相关的容器相关的等等。我们首先通过将这些收集起来再配合用户的行为比如代码变更 Diff配置变更等等保存在数据平台中。
当我们有了数据以后通过机器学习分析相关性配合人的积累比如来自专家工具运营普通开发者的知识库形成规则。
当再次产生同样问题时系统会自动推荐相关解决方案帮助开发者解决问题同时收集反馈训练模型。
通过我们的数据积累和问题广场这样的产品建设形成问题出现 》方案推送 》用户反馈 》知识贡献的闭环。目前通过我们简单的积累就已经达到了 70% 以上的匹配率未来通过闭环的知识训练相信 devops 机器人会更加智能。
作者介绍
陈鑫神秀负责阿里云云效持续交付平台和研发工具建设致力于企业研发效率、产品质量、DevOps 方向研究和探索。在阿里 6 年带领过大数据测试团队、测试工具研发团队、持续交付平台团队。对研发协同、测试、交付、运维领域都有很深的见解。
