从DevOps实践者的角度谈谈云效Flow

偶然看到云效流水线 Flow的评测活动，作为一名DevOps实践者，从事相关的平台落地工作，和一线的研发打交道比较多，对这个评测很感兴趣，就随便写点。

https://developer.aliyun.com/topic/flow2024?spm=a2c6h.27234800.J_6638147300.3.318159efXWtFlW

先说评测结论

1）你的角色是什么，你之前是否使用过CI/CD工具，你/你们团队对CI/CD 工具的要求是什么？

DevOps实践者、产品经理。用过很多，除了传统但很流行的jenkins,  还有开源的gitlab-ci, drone, 包括商业的coding, 华为devcloud, 百度云等。

对于团队来说，简单上手傻瓜，入门成本低，低侵入是最基本的要求，研发团队一般都不喜欢折腾，交付压力已经很大了，还要学习什么是CI/CD， 开玩笑，呵呵。

2）你觉得Flow在新人上手方面是否简单、是否存在什么阻碍？

我觉得Flow对新手来说，还是比较简单了，可视化编排很方便。

如果要说阻碍，可能还是了解各种术语（变量，服务连结，），如何丝滑的编排设计好的流水线。不过大部分提供的模板，也都够用了。

3）Flow的产品功能、性能、开放性等方面能满足你的需求吗？Flow哪些方面做的让你满意，哪些方面觉得不足？

从功能上来说，流水线本身需要的能力基本都具备了，可视化编排，变量，触发器，插件机制，流水线模板等等。

从开放性上来说，可能需要提高，Flow内置的插件理论上可以满足企业常规需求，不过很多企业内部有很多个性化的需求，建议可以开放插件开发能力。虽然也看到了类型Flow-CLI类型的工具，不过感觉还是包装的不太好，比如可以把这个功能更好的暴露出来，提供类似插件市场，提供更加友好的发布渠道，丰富Flow的生态。

4）对比其他CI/CD工具（商业或开源），你觉得云效流水线Flow在成本、功能、性能上是否有竞争力？你愿意推荐团队使用吗？

我经常会去体验其他CI/CD工具（商业或开源），自己所在团队没有使用效Flow（私有化场景），主要从用户体验和生态上说说吧。

• Flow本身没什么太大问题，相比于coding，我觉得云效Flow模块是更好一点的，比如插件更丰富，很细致。
• 我个人觉得，主要问题还是在整个devops的业务流程上，不够清晰吧，前几年我就吐槽过。这两年有了改进，通过菜单和工作台的方式，对各个模块进行了交互和联通。不过模块之间的业务逻辑性还是需要进一步加强，毕竟devops是端到端的交付，各个模块肯定会有交叉和联系，需要让用户感受到。

之前也写了一些评测

• https://www.zhihu.com/question/650417511/answer/3445717465
• https://mp.weixin.qq.com/s?__biz=MzI1OTYyMzE4OQ==&mid=2247485327&idx=1&sn=fea83aa6cd3910f323bafacb78b22357&chksm=ea7757f5dd00dee31ca0a5ac5b6b6afba1789b5f711fc691910df602d75d363cf4ca2265bfb8&token=1079601524&lang=zh_CN#rd
• https://mp.weixin.qq.com/s?__biz=MzI1OTYyMzE4OQ==&mid=2247484769&idx=1&sn=3cf581b4bfbbb08efe0c2f042ef8db36&chksm=ea77551bdd00dc0de827521893605da92bef57d822323063a933988884f4cf06af7cc007ed3e&token=1079601524&lang=zh_CN#rd

对于Yaml流水线的使用体验

对于传统的可视化编排，我觉得云效基本上已经很成熟了，包括各家产品在内都有这样的能力，差别主要在于整体对于可视化编排的底层执行引擎，以及编排的模式，周边生态的差别。

今天主要想聊下YAML编排，这也是目前的趋势，未来都是yaml工程师。老实说，YAML编排各家都还在起步迭代阶段，还不算特别成熟，另外用户的可接受程度也需要培养（PS： 从可视化编排到YAML编排，对于用户的要求和素质会有所增加，特别是连可视化编排都还玩不转的情况下，YAML基本就懵逼了）

提到YAML这种模式，最早应该是在gitlab-ci上面体现最早的，本来就是基于gitops的思想，一切皆代码。

结合云效YAML，探讨个人对于YAML编排需要解决的问题

1. 上手难度，gitlab-ci yaml我觉得需要一定成本的学习，掌握很多标签用法
2. 针对第一个问题，其实包括云效在内都提供了（如下图所示）插入片段的引导，这个算是第一个初级优化。

3. 尽管提供了片段引导，但是目前还是靠手工去手动复制，如果加工插入的功能是不是更好。这个倒不是重点，重点是如何像写代码一样做编辑使用，比如提供诸如“语法检查”、“智能提示”、“上下文的提示检查”，我想这样的编辑体验会好很多。

4. 进一步，需要考虑YAML和可视化之间的关系。两种思路，一种是彻底就是yaml编辑了，可视化只是在运行时候展示；另外中就是yaml和可视化之间做映射（比如可视化编排界面创造yaml）。我觉得都可以接受，后者会难一点，需要做妥协。
5. YAML化后，如何教用户去组合编排？如下图，比如我要加一个拉代码的操作，我似乎没有找到可以加的地方（这个还建立在我知道在哪里去加的基础上）。如果我是小白，不知道加的顺序，任务之间可能还有依赖关系呢？

6. 对于YAML， 目前的任务参数不支持感觉。简单说，就是对于参数变量的引入，传递，组装，感觉目前做的还太少。在复杂场景下，YAML依然需要解决这些问题。
7. 上手问题解决后，就回到YAML的本质。为什么需要这样编排？原有的可视化编排不够吗？个人观点，其实还是要践行一切皆代码，让YAML也回到代码库里，作为pipeline.yaml，导入代码，即刻直接运行流水线。

其他问题

任务/步骤名称含义模糊

例如，任务管理/步骤管管理，从中文的含义上，其实很容易模糊，意思差不多。实话说，我觉得任务管理优点鸡肋，粒度介于“步骤”和“流水线模板”之间，有点类似于“任务组（group）”的性质。我觉得，应该着力去发展“流水线模版”，作出公司级或者团队级别。

模块间缺乏逻辑性，交互不清晰

比如在代码库模块，可以新建流水线，但是点击跳到了 Flow流水线模块。我是觉得代码模块就专注于代码审核/代码扫描即可，即使是内置的扫描任务需要流水线，应该以另外方式呈现（如下面的流水线（系统来源））。

我理解，可能是因为针对某个代码库，建立流水线子组，最后所有这些子组最终聚合在流水线模块。也能理解吧，不过是否要思考“流水线”是什么？流水线本质是编排用的，更多是组织各种代码构建，各种集成任务，各种资源的。形象点说，流水线其实就是研发团队的日常业务活动的具体体现。

从流水线角度去统筹考虑，是不是会好点？如果从代码库角度去对应流水线，最终就会很散，不清晰。（PS：最近看到了APPStack的功能，我揣测可能阿里产品经理，也意识到了这个问题，所以通过另外一种形式去弥补）

如下，通过【应用】重新去组织之前比较散的实体和过程，让研发过程变得更加清晰。

总结

最后，做个简单总结，说下我对云效Flow整体的评价

1. 从功能上来说，我觉得Flow没有什么问题（比如部署这块提供了蓝绿/灰度等等），对于中小企业，特别是在阿里云上开展业务的公司，最适合不过了。

2. 不足之处，还是业务交互逻辑吧。比如从菜单开始，DevOps本身业务逻辑涉及需求到最后部署上线，最好能在一个视图，让用户体会到关联性，说白了就几个实体 【需求】-【代码】-【流水线】-【制品】-【环境】，让用户感受到之间的关系，而不是跳来跳去。逻辑上，能让用户马上知道这块负责什么（明确各自的边界和职责，关联通过数据结果体现）。

3. 制品库能力需要提高, 在我写这篇评测时候，阿里已经发布了新功能😄。不过相比于友商，还是来的有点晚。目前功能还有待完善和加强。

4. 云效本身带着阿里云的基因，所以，客观造成了对于私有化场景还是能力欠缺的（不是技术，是业务场景）。对于周边工具生态的整合，也需要提升，比如常见的sonarqube, nexus等。