阿里云效与上海移动DevOps产品横行比对分析

最近面试了阿里蚂蚁金服，蚂蚁金服的一位技术经理让我针对上海移动DevOps平台和阿里的“云效”做横向比对，着重突出目前项目的优劣势，总结如下，面试官还算比较满意，在这里也把他分享出来，希望对做DevOps的团队有所启发。

目录
1、云效与上海移动DevOps产品横行比对分析
模块对比图
上海移动DevOps产品优缺点分析
2、其他DevOps产品

---

1、云效与上海移动DevOps产品横行比对分析

看了阿里云的“云效”和蚂蚁金融云的“LinkE 持续交付”，从总的功能点来看，很多和目前我们团队做的上海移动DevOps系统类似。以下是主要功能模块比对图：

阿里云效 VS 上海移动DevOps

下面我将针对项目协作、代码仓库、持续交付、测试管理几个部分做下简介：

对于项目协作，也就是对应我们的工作空间模块，上海移动DevOps上提供了敏捷和传统瀑布双模流程，敏捷流程中包括backlog、sprint和故事看板。
对于代码仓库，上海移动DevOps中提供了代码展示、分支管理、人员管理
对于持续交付，上海移动DevOps支持配置多节点流水线，对于任意节点可以控制是否执行，支持节点参数配置，支持邮件组配置，流水线结束会通知此次流水每个节点耗时、完成情况、代码影响面。在持续集成的流水线中对接了亚信的Pass平台，实现了生成镜像，发布镜像。在发布的流水线中对接了BOMC，直接在流水线中将包scp到BOMC实施发布。
对于测试管理，上海移动DevOps集成了Sonar静态扫描（支持Java、JS、Python等）、单元测试，对接了移动的自动化测试平台。

针对于这几个模块，一些特点优势做如下分析：

1）特点

特点一：对接原有需求管理平台

在实际DevOps的接入的过程中，由于团队众多，各个团队可能本身就有对应的需求管理平台，并且DevOps平台需求拆分流程并不能满足不同团队需求，差异化明显。
上海移动DevOps系统通过将任务模型抽象出来，提供接口，对接了原有的需求平台，双向同步，让存量任务快速接入系统中。

特点二：将任务、代码提交、持续集成关联到一起

在DevOps产品使用前，团队中大家都面临着这些问题：当一次发布后，如何定位到此次发布涉及的工单任务？如果一次编译报错，如何找到导致编译报错的任务，并对涉及任务做回归？如何知道一个任务的代码提交情况？
这些问题都是由于任务、代码提交、持续集成没有关联关系。所以在上海移动DevOps项目中，我们将代码提交集成到对应的开发任务中，通过任务合并按钮出发合并，记录合并diff和提交点id，在编译记录中根据提交点id获取本次编译涉及的所有任务、代码影响面等。

特点三：自动汇总上线报告同步至BOMC

这边的上线报告是指发布生成汇总的脚本和包， 原本每次汇总上线报告都需要通过人为去汇总脚步和打包。DevOps通过自动追踪开发提交的脚本，根据上线自动汇总所以脚本，生成上线报告，并在发布时将脚本在生产环境执行。

特点四：在平台上实现git增量提交

git合并只支持分支合并，但不支持单个文件合并，我们利用Git稀疏检出机制实现了增量提交

特点五：单元测试粒度更细、案例自动生成、定时回归

单元测试粒度更细，测试到service层的方法
通过我们提供的工具自动录制单元测试案例
平台支持累计单元测试案例集
支持定时批量执行和回归
支持编译时自动选择单元测试案例

2）缺点

• 压力测试和安全测试目前没有完善
• 持续集成和持续交付没有无缝连接，这点“云效”做的比较直观
• 缺少运维模块，比如日志分析、进程监控。
• 对于上海移动的一些“古老”的项目，git flow模式不一定适用

2、其他DevOps产品

之前在DevOps大会（上海站），还简单了解过平安科技的DevOps产品“wizard”（http://wizard.pingan.com.cn）和JFrog杰蛙中国，wizard是主要做了需求梳理、持续集成、一些简单的度量管理

wizard看板

wizard故事

JFrog主要是偏向于持续交付

JFrog主页