天下没有难做的研发：解读阿里CI/CD、DevOps、分层自动化技术
本帖最后由 adminlily 于 2018-11-18 16:46 编辑在互联网时代，产品快速迭代的重要性不言而喻。不管是传统企业还是初创企业，在提升研发效能方面都有很强的需求，如果能使用一套对项目流程管理和专项自动化提效工具，来支持项目的快速迭代发布，实现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 的定义(cn/devops/what-is-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
支持多种自动化框架接入
支持项目集成相关所有自动化的自动统一触发
支持多种自动化框架不同环境触发
支持日常持续集成
支持自动化失败的原因汇总与总结
阿里分层自动化实践带来了很有意义的成果，在阿里内部，大幅提高了研发测试比，减少了重复劳动带来的加班，同时带动了更多高效工具的诞生；在研发方面，单测成本降低了，覆盖率可视化了，自测有保障了，故障降低了；在测试方面降低了测试要求，增加了工作成就感；对云效客户来说，给企业赋能了，提高了研发测试效率。
原创：云效 来源：
:lol:lol:lol:没有难做的研发
页:
[1]