阿里CI/CD、DevOps、分层自动化技术

原文地址:http://www.infoq.com/cn/news/2017/01/alibaba-yunxiao-cicd-devopsweb

在互联网时代,产品快速迭代的重要性不言而喻。不论是传统企业仍是初创企业,在提高研发效能方面都有很强的需求,若是能使用一套对项目流程管理和专项自动化提效工具,来支持项目的快速迭代发布,实现24小时持续集成、持续交付整个流程,不但能够提升研发效率,还能加强产品的竞争力!浏览器

1月12日,阿里巴巴旗下一站式研发提效平台——云效联手 InfoQ 在阿里巴巴西溪园区举办了一场旨在帮助研发团队提高研发效率的线下沙龙,邀请了阿里巴巴技术专家之岳、许晓斌、鲁小川和一佛,分享了阿里云效平台从生态规划,到 CI/CD 流程,再到自动化测试的整个技术实现过程,帮助参会者深刻了解研发提效的迫切性和重要性,以及具体该怎么作的一些思路。安全

大型互联网无线团队的云上研发闭环

之岳:阿里巴巴B2B事业群高级技术专家。2011年加入阿里巴巴,担任阿里巴巴 B2B 研发效能平台和对外云效平台的产品负责人,阿里巴巴 B2B 技术风险负责人,技术质量和技术风险架构师。精通研发质量效能平台产品,在敏捷研发、持续交付、研发团队管理等方面有丰富的经验。本次演讲中他主要分享大型研发团队如何得到敏捷快速的研发过程?如何实现高透明化的研发管理等内容。性能优化

一般状况下,业务量增长以后,研发团队也会急剧扩张,可是这给管理带来了难度,发现原先那一套研发模式和研发管理,跟不上业务的发展。之岳说,阿里巴巴内部的技术团队,也面临着一样的问题,像 B2B 技术部上千人的团队,支撑着几大核心业务,在几年前就发觉了纯人肉管理、没有系统支撑的研发模式是不合适的。为此,阿里巴巴创建了强有力的技术中台:综合管理和研发效能平台,主要目的是实行研发管理的平台化和透明化,提高研发工程效能。目前 B2B 的技术中台已经比较成熟,很好的支撑着1000多人的研发团队。服务器

阿里巴巴的使命是让天下没有难作的生意,因此衍生出的云效平台的使命就是让天下没有难作的研发。阿里云效决定上云, 提供 PaaS 和 SaaS 的服务,包含综合管理和研发工程效能,其中综合管理效能称之为“指挥部平台”。架构

综合管理效能分为六块:从整个业务战略规划,到技术资源和业务资源兵力部署,再到整个做战内容实现做战协同,来知足用户需求,最终还会根据效果来复盘,从整个流程的角度来看须要改进的地方。指挥部产品适合企业管理层、项目经理、产品经理、研发人员使用,能够实现业务技术管理平台化、线上化和数据透明化,精准化资源投入,保障资源投入的高 ROI,极大的提高资源运做的效率和效果。框架

无线测试是产品研发提效的一个重点,由于无线测试有太多的碎片化,包括品牌碎片化、设备碎片化、操做系统碎片化、分辨率碎片化等等,对于整个兼容性测试都有很大影响。因此基于此,云效考虑了一些适配测试的技术和方案。运维

  • 智能化:定制化事件,防跳出,防霸屏;
  • 有效性:覆盖安装,App登陆;
  • 定制化:首页遍历,指定场景遍历,自定义脚本,自定义执行事件。

无线测试平台包括无线适配测试和真机远程使用:分布式

  • 无线适配测试平台:支持 Android 和 iOS 的智能适配,提高随机执行有效性和覆盖度,包括随机事件百分比、定制化、防跳出功能、自定义脚本执行和固定场景Monkey 执行,而且支持 App 登录后的 Monkey 执行,控件便利。还能够为开发和测试人员提供直观的 Crash、ANR、Activity 覆盖度结果报表,提供精准的设备推荐策略,进行独立机房快速搭建和底层设备管理调度系统高效运维,有效下降 Crash率,提高 App 稳定性。
  • 真机远程使用:真机远程使用平台,有大量 Android 真机设备高效管理、真机设备Web化远程在线使用,方便快捷。而且支持Native、H5 代码远程调试,与无线适配测试平台设备共享使用,提高设备利用率。

面向微服务架构的 DevOps

许晓斌是 AliExpress 高级技术专家,目前在 AliExpress 从事微服务实施、研发效率提高等相关工做 AliExpress 在业务扩张和团队壮大以后,仍然能保持研发团队高效快速响应用户需求,而这背后的技术力量,就是许晓彬老师所讲解的 AliExpress 微服务架构及核心基础设施,DevOps 文化及工具链,以及 SRE(Site Reliability Engieering)方法。微服务

介绍一下背景,AliExpress 是阿⾥里巴巴旗下的 2C 跨境电商网站,其后台语言100%是用 Java 代码编写的;最先的代码来自 Alibaba B2B,已有10年以上的历史了;数百位工程师推崇 DevOps;且已有数百可独⽴发布的应用,这个数字还在不断增⻓。

微服务的优点是:1.每一个服务足够简单,下降学习维护成本;2.独⽴立测试和部署;3. 独⽴立扩容、性能优化更简单;4. 使⽤用新框架新技术变得更简单;5. 更容易适配团队组织架构。首先,许晓斌说,作微服务就必定要确保通讯协议是标准的,AliExpress 是多数据中心的,其服务不只分布在中国各地,在美国、俄罗斯等地区都有部署。

微服务开发发布的关键点在于,必定要走发布系统上线,这么作的目的是标准化流程化,还对提高稳定性很是有好处。在微服务的前提下,再来谈谈 DevOps,写代码的工程师是对本身的代码负责任,每一个工程师都是微服务应用的owner,这就是 DevOps 的核心理念。

  • 发布环节须要注意事项包括:预发布(Staging)环境验证、蓝绿发布、分批发布、基于用户 Beta 发布、自动回滚。
  • 监控和报警这一环节须要统一的监控系统、系统监控、应用监控和业务监控。
  • 标准化要求则须要在部署结构、命名规范、日志规范、代码结构、交互协议等方面严格要求。
  • SRE 团队在 DevOps 领域的意义也是很关键的,每一个工程师对本身的应用负责,包括对应用的功能、性能、可用性等方面时刻关注;同时,SRE 团队对网站总体可用性负责,具有应急故障处理能力,深刻掌握容灾演习,容灾切换等技术;熟悉稳定性治理技术。

最后,许晓斌引用了 AWS 对 DevOps 的定义:DevOps 集文化理念、实践和工具于一身,能够提升组织高速交付应用程序和服务的能力,与使用传统软件开发和基础设施管理流程相比,可以帮助组织更快地发展和改进产品。这种速度使组织可以更好地服务其客户,并在市场上更高效地参与竞争。

持续集成与持续交付实践之路

鲁小川是阿里巴巴B2B事业群高级专家,主要负责阿里巴巴云效平台解决方案服务输出。目前互联网电商、金融等公司业务蓬勃发展,技术团队规模和应用规模也在快速扩大、测试环境日益复杂,可是测试力量依然薄弱、应用验证成本不断提高。在这种状况下,传统企业的项目集成及交付软件已经不能知足需求。随即,这些公司硬件及中间件基础设施陆续搬到云上,企业对基于云端提高效率的持续集成持续交付的平台需求也日益迫切。鲁小川基于这样的背景,结合案例分析,讲解了如何帮助云端企业实现持续集成持续交付。

持续交付并非指软件每个改动都要尽快的部署到产品环境中,而是指任何的修改都被证实能够在任什么时候候实施部署。持续交付(Continuous Delivery)是一系列的开发实践方法,用来确保让代码可以快速、安全的部署到产品环境中,它经过将每一次改动都提交到一个模拟产品环境中,使用严格的自动化测试,确保业务应用和服务能符合预期。由于使用彻底的自动化过程来把每一个变动自动的提交到测试环境中,因此当业务开发完成时,你有信心只须要按一次按钮就能将应用安全的部署到产品环境中。

大型系统持续集成持续交付难点

  • 应用数量众多(数百甚至上千),应用之间调用关系千丝万缕、错中复杂
  • 开发团队人数众多(数百甚至上千) 
  • 并行开发的项目小需求众多(数百甚至上千),各项目小需求的商业上线时间各不相同
  • 传统的项目集成及交付软件已经不能知足需求。

在大集成环境的全网回归环境下,回归验证必然会有发布窗口限制,没办法快速交付。会暴露出不少问题,例如:功能的交付与大应用相比并没有改观;手工部署的应用更多,更复杂;自动化排查问题效率低;痛苦的回滚,剔除问题代码提交。

为了实现持续交付,该怎么作呢?单个应用实现快速交付,没有全网自动化回归,面对复杂的服务化依赖较大质量风险,给了质量保证部很大压力。既要快速交付,还要集成质量。质量向前,把一切能自动化的自动化起来,提高项目组成员的工做效能。完成这一系列过程,这其中的核心就是实现自动化。

分层自动化看上去就是一个金字塔,基本上分为两部分,业务逻辑自动化测试,和代码级别自动化测试。而这里面重点是UI自动化存在不少痛点,用下面这个公式能够说明:

  • 自动化收益=有效迭代次数×手工测试成本
  • 自动化成本=脚本建立成本+维护次数×维护调试成本+脚本失败次数×脚本排错成本

其次就是在服务化接口测试上作了不少改进,包括:无需编码,自动解析接口及所需参数,页面建立接口自动化测试用例;页面直接填写调用参数,支撑多种参数类型;直接指定IP进行服务调用。

在线性能压测方面,实行了在线编辑性能压测脚本;分布式集群压测执行调度,执行结果实时统计;Linux服务器资源在线监控。

经过一系列的改进,给 质量保证团队带来的变化很明显,好比:开发测试比逐年提高,更多的开发资源投入在产品研发上,支撑业务快速发展;测试资源经过高效的自动化工具产品,提供分层自动化测试套件进行自动集成;业务技术团队判断是否须要测试人员接手人工测试;能够有不通过手工测试的需求发布上线,可是不能没有质量数据监控的需求发布上线。

阿里巴巴CI/CD之分层自动化

一佛是阿里巴巴B2B事业群高级产品经理。从事多年互联网系统的研发和测试工做,目前主要负责云效分层自动化测试的产品设计。由于自动化测试在实践过程当中,老是碰到各类各样的问题,致使进入自动化测试盲区。因此,一佛就根据当下环境并结合解决案例,来说解了如何把握分层自动化的分层策略,如何将分层自动化融入到项目流程中,如何作好自动化测试等现实问题。

自动化诞生的背景,一佛说,手工测试的效率低下,尤为是发布频繁的状况下,回归量大,成本高,重复劳动,枯燥多。而自动化以后,就能够替代重复劳动,N次测试,只须要投入一次就够了。

可是自动化也是有烦恼的,问题就在于成本高(代码能力、自动化框架、IDE 准备、调度、多环境),效果差(浏览器影响、执行机影响、依赖环境影响、脚本健壮性不强),覆盖率低(框架不万能、上下层难全、接口参数排列多),及时性低(代码变动频繁、遗漏的变动、项目结束才发现)等等。

因此说,为了下降成本,提升准确性,就要考虑下降人员成本、制做成本、运维成本、运行成本,同时扩大覆盖率、数据独立、提供好的方法和脚本。固然,就须要实行分层自动化。

在阿里实践分层自动化就须要不少分层工具,包括配置管理Aton、UI测试的AUI、单元测试的Amon、环境管理的Aenv、接口测试SAT、性能测试Perf、集成自动化Pre等。这里来介绍几个革命性工具:

UI自动化—AUI

  • 创新型web-ui自动化测试框架,无需安装复杂底层环境和 IDE
  • 建立和维护脚本,都无需接触代码,所有为 Web 页面可视化使用
  • 支持本地回放,支持云端执行,解放机器,释放双手
  • 支持项目持续集成,线上监控等各类复杂场景

接口自动化—SAT

  • 可视化的接口测试,无需编写代码
  • 支持普通接口调试和复杂后台交互的接口测试的用例沉淀
  • 支持主干,项目用例的沉淀与回归
  • 支持项目持续集成

性能压测—Perf

  • 基于 Jmeter 的性能压测平台
  • 集脚本,场景,压测,监控和报表为一体,可快速施压的平台
  • 支持多种协议,适合 http,service 接口等测试
  • 比 LoadRunner 易上手,更轻量

单元测试—Amon

  • 可对代码主干及各项目分支进行单测集成
  • 对有代码变动的项目分支自定义频率集成
  • 对有代码变动的应用主干自定义频率集成
  • 拥有单测用例结果、覆盖率结果、静态扫描结果、sonar 代码分析等质量数据

集成自动化—Pre

  • 支持多种自动化框架接入
  • 支持项目集成相关全部自动化的自动统一触发
  • 支持多种自动化框架不一样环境触发
  • 支持平常持续集成
  • 支持自动化失败的缘由汇总与总结

阿里分层自动化实践所带来的成果是很是有价值的,在阿里内部,大幅提升了研发测试比,减小了重复劳动带来的加班,同时带动了更多高效工具的诞生;在研发方面,单测成本下降了,覆盖率可视化了,自测有保障了,故障下降了;在测试方面下降了测试要求,增长了工做成就感;对云效客户来讲,给企业赋能了,提升了研发测试效率。

相关文章
相关标签/搜索