如何实现 7*24 小时灵活发布? 阿里技术团队这么做

阿里妹导读: 研发效能分为两块, 一是用技术的更新来提升效率; 二是提高整个技术生态中的协同效率, 激发技术活力. 阿里巴巴技术团队在此基础上要实现的终极目标是打造 7*24 小时灵活发布的通道, 以及提供更快的业务代码迭代能力. 今天, 阿里巴巴高级测试开发专家傲野为你带来关于研发效能的一些思考, 希望对你有启发.

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

一, 系统

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

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

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

二, 架构

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

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

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

三, 配置管理

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

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

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

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

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

体现在项目上的流程为:

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

平台化的支持: 早期配管的人肉化, 也造成了代码集成和部署的效率很低. 不同角色之间的协同靠人来完成. 因此在那个背景下, 还需要一个配套的 PMO 组织来保障. 在这样一个历史背景下, Aone(对外版本是云效)也孕育而生, 从平台化的角度来解决研发过程的协同, 构建, 集成和测试几个复杂的过程. 为了更清楚的了解那个时期的痛点, 我找了 2009 年左右的 Aone 的蓝图, 可以管中窥豹(这个时期我并没有亲自经历过, 只是针对于当时的前辈做了些访谈和收集了一些资料). 我猜想也正因为这条道路面向未来解决问题造就了现在的 Aone 平台.

四, 测试

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

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

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

1, 测试的层次增加了.

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

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

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

它的实现逻辑如下:

五, 文化

至此, 真正所谓的 7*24 小时业务的持续交付通道已经完全打造出来. 我们再回顾一下.

Aone 云效流程图

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

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

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

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

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

来源: https://yq.aliyun.com/articles/702470